From the #6492 comments today, on WeKan 10.40 with real users:
SyncedCron: Fatal error encountered (uncaughtException):
TypeError: self._pendingRemoveFunction is not a function
at Session.send (packages/ddp-server/livedata_server.js:362:14)
at Session._stopSubscription (packages/ddp-server/livedata_server.js:823:10)
at Session.unsub (packages/ddp-server/livedata_server.js:562:12)
snap.wekan.wekan.service: Main process exited, code=exited, status=1/FAILURE
snap.wekan.wekan.service: Scheduled restart job, restart counter is at 4.
It is a state-machine hole in Meteor's ddp-server. `_removeSession` sets
`session.messageQueue = []` and `session._pendingRemoveFunction = remove`; when
`remove()` runs it clears the function and deletes the session but LEAVES the
queue - an empty array, which is truthy. `Session.send` then takes the queueing
branch for a session that no longer exists, and the message past
`maxMessageQueueLength` (100 by default) calls that now-null function. It runs
from an Immediate, via unsub -> _stopSubscription -> send, with no try/catch
above it, so it is an uncaught exception - and synced-cron's handler exits the
process on one. systemd restarts, every user is disconnected, new cards stop
arriving until a reload, and the restart loop reads as "WeKan is slow and the CPU
is high", which is exactly what the reporter describes.
It needs a busy server: a session has to disconnect while more than ~100 further
messages are still addressed to it. That is why it shows up with fifty users and
never in a quiet test.
The guard patches Session.send once, from the first connection (the Session class
is not exported, so an instance is how the prototype is reached): a queue with no
remove function belongs to a session that is already gone, so the queue is
dropped and send() takes its ordinary path - which, with no socket, does nothing.
Nothing is lost that was not already lost, the disconnect-grace queue for a real
reconnect is untouched, and a valid overflow still removes the session.
tests/ddpSessionSendGuard.test.cjs replays the upstream state machine: it asserts
the unguarded version really does throw on the 101st message, that the guarded
one does not, that a session still waiting for its client keeps its queue, that a
legitimate overflow still calls the remove function exactly once, and that a live
session sends as before.
NOT verified here: there is no server in this environment, so this is reasoned
from the ddp-server source in .meteor/local and replayed against a model of it.
The high CPU the issue opened with is a separate thread (the FerretDB
$changeStream busy loop); this fixes the crash-restart loop reported today.
Thanks to bluetopaz1204, Nissulya and xet7 !
Fixes#6492,
WeKan used colourful Unicode emoji as its icon set in 8.00-8.24 only; before and
after, the icons are Font Awesome 4.7. A handful of emoji had survived that
change - every notification type, the board star, the vote-against thumb, the
spent-time badge, the reaction and add buttons, the list width toggles, the
bookmarks star, the back arrow, the custom-field pencil, the notification bin,
the sidebar's plus and hash, the four date badges in cardDate.css and
minicard.css, the mobile drag handle, the multi-selection tick, and the gantt
day markers. Each of those is a different picture on every platform, at a size
and colour the stylesheet does not control. They are Font Awesome glyphs now:
either an `i.fa` element, or the codepoint (`content: "\f11e"`) with the font
named, since `time::before` is not an `.fa` element. The helpers that produced an
emoji return a class name instead, and their templates render an `<i>`.
"Grey Icons" in Member Settings existed to grey exactly those emoji. It ran a
MutationObserver over every rendered subtree, for the whole session, wrapping any
text node that was one of ~50 emoji in a span it could greyscale - and only 13 of
those emoji were still anywhere in the app. With them gone it has nothing left to
find, so the feature is removed whole: the menu entry, the click handler, the
`toggleGreyIcons` method, the `hasGreyIcons` helper, the `profile.GreyIcons`
schema field and its published-fields entry, the `userGreyIcons` publication and
its subscription, unicode-icons.js/.css and the feature import, twelve
`body.grey-icons-enabled` CSS rules across six stylesheets, the `grey-icons`
string in all 147 language files, the field in public/api/wekan.yml and
wekan.html, and the two mentions in docs/DeveloperDocs.
The language flags in the language picker stay: Font Awesome 4.7 has no flags.
tests/fontAwesomeIcons.test.cjs fails on an emoji in any template or any CSS
`content:`, checks the date badges name the font and use the four codepoints,
checks the icon-producing helpers return class names, and checks that no part of
the removed feature is left anywhere.
Thanks to xet7 !
Two gaps, and together they meant most of the test suite never ran anywhere.
The flow ran six jobs - mocha, the import regression, the Node E2E harness and
the three browsers - and no npm unit script at all. Everything in
`test:unit:node` and `test:unit:all` was therefore never executed by "Run ALL
tests": that is the ~165 .cjs guards plus the sticker, Trello and OAuth2 suites.
A guard that never runs guards nothing, and several of those were written to fail
the suite when a fix regresses. Both scripts now have a `unit` job that runs
`meteor npm run test:unit:all`. It needs no server and no browser, so it starts
beside Mocha and the import regression in the parallel flow, and takes its own
step in the sequential one; it is counted, waited for and reported in both, with
its own ../log/<run>/wekan-alltests-unit.log.
And the scripts themselves were incomplete: 72 suite files existed that no npm
script mentioned - addCardTabSubmit, apiLogout, boardRepair, exportHTMLXss,
ldapPasswordLoginGuard, oidcProfileMerge, userDeletionCleanup and 65 more. They
are all in `test:unit:node` now; `tests/rtl.test.js`, which documents itself as
runnable by node, joins `test:unit:all`. `tests/all.test.js` stays out on purpose:
it is the Meteor mocha ENTRY POINT that imports the two suite indexes, and it runs
under `meteor test`, which is the mocha job.
tests/testsAreRegistered.test.cjs - which already caught suites missing from the
mocha indexes - now also fails when a plain-node suite is in no npm script, and
when the ALL-tests flow stops running that script. tests/buildScriptParity.test.cjs
pins the job in both files: the command, the launch, the key sets, the label, the
counter, and in the .bat both flows starting it, waiting for it and reporting it.
NOT verified here: there is no node in this environment, so those 72 suites have
never been executed anywhere. Some may fail on the first real run - that is the
information this change buys, not a regression it introduces.
Thanks to xet7 !
The two strings the #6531 setting added - the Member Settings entry and the
sentence explaining what OFF does - were the English source in every language,
which is what the pull leaves behind for a string that is untranslated
everywhere.
They are translated directly, per CLAUDE.md: written here, from each language's
own existing translations, with no external service. The word for "card" is the
one that file already uses - kortti, Karte, carte, tarjeta, cartão, scheda,
kartica, картка, карточка, כרטיס, بطاقة, कार्ड, カード, 카드, 卡片, kadi, ikhadi
- so the new strings read like the rest of the file rather than like a
dictionary.
142 languages, and English plus its 11 en-* variants keep the source by design.
Only placeholders were touched: a file whose value already differed from the
English source was skipped, so no human translation could be overwritten - which
is also why the count of files written is 135 rather than 142 (seven of them are
symlinks to a language already written). The two keys are the only thing that
changed in the whole directory, key order and the 2-space indent are untouched,
and every file still parses.
These stay LOCAL: filled strings are never pushed to Transifex, so none of them
can masquerade there as a human translation.
Thanks to xet7 !
Its upper part - the panel title, the tabs, the members row - was underneath the
two header bars, so the sidebar appeared to start in the middle of itself.
On a phone the sidebar is `position: fixed`, and it has to be: the board behind
it is wider than the screen, so an absolutely-positioned sidebar pins to the far
right of the BOARD and shows as a narrow strip. But fixed means "against the
viewport", and it was pinned at `top: 0` - the top of the screen, which is where
the header bars are.
There is no number to put there. The header is the quick-access bar plus a board
bar whose buttons wrap to one, two or three rows depending on the language and
the window width; every fixed value would be wrong for some of them. So the
header measures itself: client/lib/utils.js publishes its rendered height as
`--wekan-header-height` and the sidebar starts at that. A ResizeObserver keeps it
current, because the buttons re-wrapping does not fire a window resize; an
orientation change and a window resize are handled too, and a missing header
means 0 - the old behaviour - rather than a thrown TypeError.
tests/sidebarBelowHeader.test.cjs pins the rule and the measurement, including
that `top: 0` does not come back.
Thanks to xet7 !
The guard replaced `check(boardId, String)` with `Match.test(...)`, and every
subscription then failed with
Exception from sub board id ... Error: Did not check() all arguments during
publisher 'board'
This app runs with audit-argument-checks: a publisher that returns without having
check()ed every one of its arguments is failed by the audit, and `Match.test` is
not checking - it only asks. So the server no longer died, but no board could be
subscribed to either.
Each guarded publisher now marks its arguments with `check(x, Match.Any)` - which
satisfies the audit and cannot throw - and validates them with `Match.test`
immediately after. `board`, `boardCardsWindow` and `boardCardsLoadingMode` all do
this. Checked the other publications too: `activities` was the only other one
that looked unchecked, and it does check its argument, over several lines.
tests/publicationArgumentGuard.test.cjs now requires both halves - every argument
marked with Match.Any, and the marking before the validation - so removing the
check() again fails the suite instead of the server.
Thanks to xet7 !
From the dev server log:
Match error: Expected string, got null
at Subscription.<anonymous> (server/publications/boards.js:481)
SyncedCron: Fatal error encountered (unhandledRejection)
=> Exited with code: 1
`publishComposite('board')` starts with `check(boardId, String)`. A subscription
arrives with a null board id, check() throws, and a throw inside an ASYNC
publisher escapes as an unhandled promise rejection - which this app treats as
fatal and exits on. So one bad subscription stops the server for everyone, and
the arguments come from the client: any client can send it, logged in or not.
The app was in fact sending it itself, from a popup that read
`Session.get('currentBoard')` on a page that has no current board.
Both halves are fixed. The publisher TESTS its arguments instead of checking
them: a subscription that names no board publishes nothing (publishComposite
treats a falsy return as "no publications" and readies the subscription), so the
client gets an empty result and the process stays up. The same guard is on
`boardCardsWindow` and `boardCardsLoadingMode`, which are async publishers with
the same shape. And the client no longer sends a subscription for a board id it
does not have - the popup's Session read, two <select> values, a new board id
that may be undefined when the insert failed, and a template container with no
linked board.
tests/publicationArgumentGuard.test.cjs replays the guard for null, undefined,
empty string, a number and a selector object, checks the guard runs before the
publisher touches the id, and fails on an unguarded board subscription in the
client file this came from.
Thanks to xet7 !
The icons still took four rows - title, seven, three, hamburger - because the
rule that makes each button a flex item of the bar was in boardHeader.css, and
`#header #header-main-bar .board-header-btns-group { display: flex }` in
header.css has the same specificity and loads later. So the groups never became
`display: contents` and the whole set stayed one unbreakable item, which is also
why the hamburger after it got a row to itself. Same lesson as the button
metrics: this pair of files needs the rule in the one that wins.
Lists still stacked in desktop mode, because boardBody.css lays the whole canvas
out for a phone by WIDTH: `display: block` on the swimlane with `overflow-x:
hidden` on the wrapper, which makes every list a full-width row and drops the
"add list" form under the last list rather than beside it. That is mobile mode's
layout now. Desktop mode gets the desktop board on the same narrow window: the
swimlane is a flex ROW that scrolls sideways, so the lists run left to right and
the add-list form is the last item of that row - the right in LTR and the left in
RTL, since a row follows the writing direction rather than a hard-coded side.
tests/narrowWindowLayout.test.cjs pins both, including which file the contents
rule has to live in.
Thanks to xet7 !
Five things from the same two screenshots, and one theme: what belongs to the
MODE the user chose, and what belongs to the width of the window.
The board bar's buttons still took three rows in desktop mode. The metrics were
written in boardHeader.css, and Meteor loads client/components/boards/ before
client/components/main/ - so at equal specificity header.css's `margin: 0 6px`
won, and the 2px never applied. They are written in header.css now, with
`!important` so `.mobile-mode .board-header-btn` (9px/21px of padding on every
one of these buttons) cannot take them back either. 44px target + 2px each side =
48px: seven fit a 375px row, so eleven icons take two rows in both modes.
The sidebar hamburger was pinned to the top right corner, beside the title, with
the icons below it. It is the LAST button at the right of the last row now: in
the flow, with an auto start margin, so it never covers a button and reads as
what it is.
The user avatar was cut in half in MOBILE mode only. Same cause as the buttons:
the drag-handle toggle in the top bar is also a `.board-header-btn`, so mobile
mode gave it 42px of padding for one icon - the width the avatar needed. It is
sized for what it is now, in both modes.
Lists stacked one per row in desktop mode. That layout is chosen by WIDTH
(max-width: 800px), so a phone in desktop mode got the phone board: one list per
row instead of lists side by side. The stacking rules are `body.mobile-mode` now
- the same class the rest of the mobile board layout uses.
The minicard's drag handle sat near the bottom of the card in desktop mode. The
full-height thumb column is chosen by `pointer: coarse`, which is true of a
finger whatever mode the user picked; in desktop mode the compact handle in the
corner, under the menu button, is what belongs there. That block is scoped to
mobile mode as well.
tests/narrowWindowLayout.test.cjs follows all five, including that the button
metrics live in the file that wins and that the mode-based rules are mode-based.
Thanks to xet7 !
Eleven icons took three rows under the title. Each button was ~20px of icon
inside 10px of icon margin inside 6px of button margin - 52px of a 375px bar for
20px of icon - so five fitted a row.
A 44px touch target with 2px between buttons is 48px each: seven fit a row, so
the icons take two rows, and the first of those shares the title's row since the
button groups are `display: contents` there. 44px is the minimum comfortable
touch target, so this is as tight as it goes without making them harder to hit -
one row would need 34px each, which is smaller than a fingertip.
tests/narrowWindowLayout.test.cjs does the arithmetic: it fails if the metrics
stop fitting eleven icons in two rows, or if the target drops below 44px.
Thanks to xet7 !
The avatar sat above the bell and against the right edge of the screen. Its
wrapper carries `top: -5px` - a leftover from the desktop bar, where the username
sits beside it - which lifts it off the row's centre line, and `#header-user-bar`
carries 10px of padding on each side, which is 20px of a 375px bar spent on
nothing and is what pushed the avatar past the edge. Neither applies on a phone
now. The chips I put behind the mode-toggle icons cost width in the same row, so
they are trimmed from 6px of side padding to 4px.
"My Boards" had moved to the middle of the second header bar, and that was mine:
the phone rule that makes the All Boards page a flex column was written for a
bare `.wrapper`, and header.jade puts `wrapper` on #header-main-bar on every page
that is NOT a board. So the header bar became a flex column too, and the bar's
own `align-items: center` then centred its items across it. Scoped to
`#content .wrapper`: the page wrapper is inside #content, the header bar is not.
(The `height: 100vh` that rule replaced was landing on the bar as well.)
tests/narrowWindowLayout.test.cjs pins the avatar's placement and fails on a bare
`.wrapper` rule in the phone block; tests/boardListScrollChain.test.cjs follows
the scoped selector.
Thanks to xet7 !
Four things from the same two screenshots, all on a phone and all the same in
mobile mode and desktop mode, because every rule here is chosen by WIDTH.
The board's buttons started on a row of their own under the title. Every group is
one flex item - deliberately, so a long title pushes them all down together - but
that also means they move as one block even when there is room beside a short
title for several of them. On a phone the groups are `display: contents` now, so
each button is a flex item of the bar itself: they start immediately to the right
of the title and wrap only when the row runs out.
The sidebar hamburger sat on a row below the buttons, with the empty band that
goes with it. It was already meant to be pinned to the top right corner - by two
rules scoped to `body.board-view`. Nothing in this app ever sets that class:
it is written in 67 CSS rules and added by no code, so those rules have never
applied, in either mode. The width-based copy asks `:has(.board-header-sidebar-
toggle)` instead - is the hamburger there - which is the thing the rule actually
cares about. (The other 65 dead `body.board-view` selectors are left alone: they
are a separate question, and turning that class on would flip every
`body:not(.board-view)` rule in the header at the same time.)
The mobile/desktop toggle did not say which mode was on. The two icons differed
only by colour - #000 for the active one, #666 for the other - which at 14px on a
phone is no difference at all. The current mode is now a filled chip in the
active theme's accent with a white glyph, and the other side is faded to 0.35.
The avatar sat higher than the bell beside it, and its initials sat low in the
circle. The first is a 4-6px BOTTOM margin from the mobile blocks, which in a
centred row lifts an item by half of it; the bell and the avatar have no block
margin now. The second is the initials SVG: `y="11"` of a 15-unit viewBox is 73%
down, and font-size 16 in that box is taller than the box - it is `y="50%"`,
`dominant-baseline="central"` and font-size 10 now, for the user, organization
and team avatars alike.
tests/narrowWindowLayout.test.cjs pins all four, including that these rules do
not hang off body.board-view.
Thanks to xet7 !
Reported against 10.10, again against 10.37, and again against 10.38 after two
fixes that made the numbers more accurate instead of removing them. An inner
scroller only works when every ancestor between it and the viewport has a
DEFINITE height, and on a phone this chain was built out of viewport arithmetic:
.wrapper height: 100dvh - but it lives INSIDE #content,
which already begins below the
two header bars, so its bottom
sat about two bars BELOW the
screen, and it is overflow:hidden
.boards-layout (no height) - so the `height: 100%` under it
resolved to auto
.board-list height: calc(100dvh - 120px) - a guess at everything above it.
On a phone that is ~226px: two
header bars plus a search header
that wraps to two rows. The list
box therefore reached ~100px
below the screen: it scrolled
internally, but its last rows
were under the fold where no
gesture could bring them.
That is "you cannot scroll the board list", and no amount of dvh could fix it:
both the wrapper and the list were measuring the wrong thing.
There is no viewport arithmetic below `body` now. The page is 100dvh (with the
vh fallback), and from there it is a flex chain: the wrapper takes what #content
has left, the layout takes what the wrapper has left, the board column is a flex
column whose header keeps its own height, and the list takes the rest with
`min-height: 0` so it may be shorter than its content - which is what makes it
scroll. It ends exactly where the screen does, whatever the bars above it are.
The left menu is bounded the same way, and `.mobile-view` no longer carries its
own copy of the magic number, so both modes scroll by the same mechanism.
tests/boardListScrollChain.test.cjs checks every step of the chain and fails if
"viewport minus a guess" comes back; tests/mobileViewportHeight.test.cjs, which
pinned the previous attempt, now asserts the opposite for those three containers
and keeps the page-level dvh rule.
NOT verified here: there is no phone in this environment and Playwright's fixed
viewport has no browser toolbar, so this is reasoned from the source. What IS
verified is that the chain now has a definite height at every step, which the
previous two attempts did not.
Thanks to mimZD and xet7 !
Fixes#6488,
Both scripts built the bundle only when .build/bundle was MISSING - which is
exactly the case where a bundle exists and is stale. The :3000 test server runs
that precompiled bundle, so Node E2E and every Playwright browser were testing
whatever was built last time, and the run passed or failed on code that is no
longer in the working tree. That is the one thing a test run must never do.
Both now delete .build and build before starting anything, every time, and stop
with an error if the bundle is missing afterwards rather than running the suite
against nothing. build.bat gets a :rebuild_for_tests subroutine with the same
steps as its Setup "Build WeKan", called from both the parallel and the
sequential flow. The line that promised "No recompile: your existing build is
reused" is gone from both.
build.bat was also behind build.sh - the menu that is used - by two entries,
which is the drift this pairing collects:
* Dev server: CUSTOM PORT + SUBDOMAIN, asking for the port and the ROOT_URL
host, with build.sh's rule for what is local and what is proxied;
* Tests: Install Playwright browsers, natively with system dependencies (the
Docker fallback build.sh uses for WebKit on Linux arm64 has no place here).
Both .bat menus renumber and dispatch the new entries.
tests/buildScriptParity.test.cjs keeps the two together: it fails if either
script stops rebuilding before the tests, if a build.sh menu entry has no
counterpart in build.bat, if a Docker compose file one can start and the other
cannot, if a .bat menu prints numbers it does not dispatch, or if a goto lands on
no label.
Thanks to xet7 !
They were placed by whatever margin happened to win: one auto margin on the zoom
pill pushed the pill, the bell and the avatar to the end of the row as a packed
group, so the bell sat against the pill with all the empty space beyond it, and
the avatar's distance from the edge was whatever was left over - different in
mobile mode and in desktop mode on the same phone.
Below 800px - a width, so both modes get it - the free space is shared around the
bell instead: an auto margin on EACH side of it puts it midway between the zoom
pill and the avatar, and the avatar keeps a fixed 12px gap to the right edge
rather than being flung against it. Exactly one auto margin belongs to the bell
pair; the user bar's is cleared, since two would split the row and separate them
again.
Both `.iphone-device` variants are named in the selector list. That fallback sets
these margins with `!important` and two classes more than a bare id selector, so
without naming them the placement would apply everywhere EXCEPT the phone this
was reported from. The cascade was resolved property by property, shorthand
`margin` included, rather than assumed.
tests/narrowWindowLayout.test.cjs pins the two auto margins, the single fixed
gap, and that the iphone-device variants are named.
Thanks to xet7 !
Two things differed between mobile mode and desktop mode on the same phone.
The board tile's drag handle was a 26px circle in mobile mode and a 40px one in
desktop mode - two rules for the same handle, `.board-list.mobile-view
.board-handle` and the `.board-list .board-handle` inside the phone media query.
On a ~97px tile the big one covered a good part of the tile it was meant to sit
on. Both are the smaller one now, which is still well over the ~24px a finger
needs; the ≤360px block said 40px too, and says 26px now.
A workspace had no readable name in EITHER mode. The row packs a drag handle, a
folder icon, the name, a menu button and a count chip, and the rule for the phone
said the name "must give way to the fixed items around it". It gave way
completely: those items at their desktop paddings come to ~130px, the menu column
on a 375px phone is ~145px, and the name was laid out in the 15px left over. The
fixed items are trimmed to what they need on a phone - about 90px together - and
the name is given a floor of 3.5em it may not shrink below, so there is always a
name to read, with an ellipsis when it is long. It stays clipped to its own box,
so it cannot spill over the menu button, which was a separate bug and is pinned
by its own assertion.
tests/allBoardsPhoneRow.test.cjs reads the sizes out of the cascade rather than
trusting the comments: every phone handle rule is 26px, the name has an em floor
and an ellipsis, each fixed item is trimmed, and the clip is still there.
Thanks to xet7 !
v10.38 was tagged and released at 15:24; the work that followed was written into
that release's section, which says those fixes shipped in it. They did not.
Everything committed after the v10.38 tag now sits under a new
`# Upcoming WeKan ® release` above it: the four fixes - the Admin Panel old-URL
redirect, All Boards fitting a phone, the zoom number back inside its pill, and
the narrow-window layout - moved out of v10.38 unchanged, and the changelog
format work and the CLAUDE.md Hall of Fame rules are recorded beside them. The
release-only commits (the changelog edits themselves) have nothing to say and are
not listed.
Checked both ways: every post-release commit that changed something is mentioned
in Upcoming, and every commit still filed under v10.38 is an ancestor of the
v10.38 tag.
Thanks to xet7 !
The phone/desktop toggle writes an explicit choice and Utils.isMiniScreen()
returns it as-is, so a phone whose user picked DESKTOP mode is not a mini screen
and its body carries no `.mobile-mode`. Every fix written for one of those two did
nothing there - while the viewport was still 375px wide. Three of them showed up
in the same set of screenshots.
"Create board" opened 160px from the left with its right half off the screen, so
its Create button could not be reached. The geometry laid the popup out as a
floating box of min(380px, 55vw) anchored to the button, while popup.css - which
has given every popup the full width and its own 48px header below 800px for
years - then made it 375px wide. The two disagreed, and the inline `left` from the
geometry stayed. Now the geometry returns the top-left corner for any viewport
that narrow, and the CSS pins the sheet with `position: fixed` and
`inset-inline-start: 0` (with `!important`, because left/top are inline styles),
so neither can drift from the other.
The board bar's hamburger was pushed onto a third row of its own, with the empty
space that goes with it: it comes after the buttons in the flex order, and a flex
line breaks in order. The three mobile-mode rules that take it out of the flow and
pin it to the corner - and reserve its width as end padding - are now also written
by width.
The quick-access bar was still wider than the screen, so the avatar was cut off at
the right edge. The drag-handle toggle's arrows and its check/ban were breaking
onto two lines, which reads as two buttons; they are one line now. The mode toggle
gave up 21px of padding on each side of its two icons, and the logo 20px of its
cap - about 60px of a 375px bar, which is what the avatar needed. The logo cap
names the `.iphone-device` variant explicitly, since that one sets 84px with one
class more and would otherwise win.
tests/narrowWindowLayout.test.cjs replays the sheet decision at 375/800/801px and
pins each of the three rules; the popupOffset suite gains the narrow-window case
beside its mini-screen one.
Thanks to xet7 !
Two things had gone wrong with the zoom control on a phone, both visible in the
same screenshot: the white rounded pill was empty, and "100" sat to the right of
it in tiny type, half under the notification bell.
The pill was allowed to shrink below its own contents (`flex: 0 1 auto` +
`min-width: 0`, from the change that made the bar fit the screen). A flex item
that shrinks past its content does not clip it - the background box ends where
the width says, and the text carries on outside it. So the white area and the
number it belongs to were laid out at two different widths. The pill is sized by
what is in it now, and what is in it is made small instead: a compact "100%" and
a 46px input for when it is clicked to be edited.
The tiny type was `font-size: 0.7em` on a bar whose own text is 12px - about 8px,
the smallest text on the page, and set with `!important` on selectors specific
enough to beat anything written later. That declaration is now a plain 14px, the
size of the rest of the bar, which is also why the pill stays narrow: at 14px
"100%" needs about 40px.
The base rule also caps the pill at `max-height: 24px`, shorter than 14px text
with padding, which pushed the number against the top edge; the mobile rules lift
that cap and centre it. Every one of these declarations is `!important` because
the "Make zoom controls larger" block at this very width sets 21px paddings and
margins that way - the cascade was checked selector by selector, not assumed.
tests/mobileAllBoardsFit.test.cjs pins it: the pill and the number never shrink
below their contents, the cap is lifted, no zoom rule sizes the text as a
fraction of an already small bar, and the number is at least 12px.
Thanks to xet7 !
The rule named one collapsed cell; the index page now has two, each with its own
column's name as the summary - "Process" over how the report arrived, "Details"
over the story of the vulnerability. The remaining six cells, which are what a
reader scans, stay open.
Thanks to xet7 !
The index page's table grew three columns - Icon, Stars and Process - by taking
the icons out of the Vulnerability name cell and the stars and the "how the
report arrived" sentence out of the "Responsible Security Disclosure by" cell.
Written down here so the next security entry adds eight cells in that order
instead of the old five, and so the stars stay a column that can be compared down
the page rather than drifting back into the reporter's cell.
Thanks to xet7 !
The Vulnerabilities column of hall-of-fame/index.html carries the whole story of
every vulnerability, so each of those cells is a <details> with a "Details"
summary now - the table reads as a list, and the one being read opens where it
stands. Whoever writes the next security entry should not have to infer that from
the file.
CLAUDE.md now states it with the exact shape: only the LAST <td> of a row, the
plain word "Details" as the summary, a blank line under it, the cell's contents
otherwise unchanged, and the four identifying cells (CVE, name, date, reporter)
plus the header row left alone.
It also states the exception: the per-vulnerability subdirectory page is NOT
collapsed. That page was opened on purpose, for one vulnerability, so its cell
stays open and its prose Details section below the table stays as it is. Only the
index, which lists them all, hides them behind a summary.
Thanks to xet7 !
The rules described the shape the file had for one commit, not the one it has:
the "Version" list became a collapsible block inside Platforms rather than a
heading of its own, and the TODO Later introduction became one too. Whoever adds
the next entry should not have to reverse-engineer that from the file.
So CLAUDE.md now states the file's shape top to bottom - Platforms (with its
Version block), TODO Later (with its "Carried to a future release." block), then
the releases newest first, and NOTHING else as an `#` heading, including a
wrapped line that begins with an issue number. It states the exact <details>
block an entry is, line by line: the summary on one line, blank, body, blank,
close, blank between blocks. It states that a summary is plain text with no
markdown, ends with a full stop and its Thanks, and links its own commit; that a
change with nothing to reveal stays a plain bullet, as does a dependency batch;
that a TODO Later block has no <a> and no Thanks; and the order of a release's
subsections, ending with the "Thanks to above GitHub users" line.
tests/changelogFormat.test.cjs follows the file as it is: two non-release
headings, the Version block inside Platforms, the TODO Later opener, and the
CLAUDE.md rules it checks are named by their new wording. One 2021 heading that
had lost its `v` (`# 4.93`) is normalised, so "every other heading is a release"
is true rather than nearly true.
Thanks to xet7 !
The previous pass went the wrong way about #6524. It made every entry a title and
moved the story into the commit message, so the changelog told a reader WHAT
changed but nothing about why - and it showed the commit hash as the link text,
which is a number nobody can do anything with without leaving the page.
Both halves are here now. Every entry is a <details>: the <summary> is a SHORT
description of what was done, and it IS the link to the commit - the hash is in
the href, never on the page - followed by the "Thanks to" line. Clicking it
reveals the long description below, word-wrapped at 80 columns, with its links,
code and emphasis intact. A change with nothing more to reveal stays a plain
bullet, because a <details> whose body repeats its summary is noise.
977 entries across every release section were converted, and the ones the old
prose format had left malformed - an entry whose closing `](url)` sat at column
0, a summary that swallowed the following entry's links, a title that began with
a stray bracket - were repaired rather than carried over. Nothing was dropped:
every URL the file had is still in it, and every heading is where it was.
The top of the file is now two named sections, Platforms and Version, instead of
two unlabelled lists. TODO Later is <details> too, with one difference stated in
CLAUDE.md: its summary carries NO "Thanks to", because nothing there is done yet,
so there is nobody to thank.
tests/changelogFormat.test.cjs checks the whole file against those rules: the
opening sections, summary length, that a summary is one closed line holding no
markdown link, that no hash is ever a link's visible text, that no long URL is
visible, that no wrapped line starts with `#` (which Markdown would render as a
heading), the TODO Later exception, and the 80-column wrap.
Thanks to xet7 !
Two things from the same screenshot.
The board titles were laid out TWO CHARACTERS per line - "Da" / "ta". The drag
handle is one absolutely-positioned ~26px circle, but the space for it was
reserved three times on the way down: 32px on the `li`, 30px on the tile and
50px on `.details`. On a ~97px phone tile that is more than the whole tile, so
the title was laid out in what was left, about 27px. It is reserved once now,
on the tile, and not at all when the handle is not rendered - with drag handles
off there is nothing there to reserve for, which is the state the screenshot was
taken in. The `.mobile-view` tiles already had this fix; the plain ones, which
is what a phone gets when the list is not in mini-screen mode, did not.
The page could also be dragged sideways: the avatar sat past the right edge and
the board list moved with the page when you did. On a small screen the
quick-access bar is `flex-wrap: nowrap` with `overflow: visible` - deliberately,
so an item that does not fit spills rather than disappears - and every item
declares `flex-shrink: 0 !important`. Nothing could give way, so the row was
wider than the screen, and a visible overflow is scrollable overflow. The widest
item by far was the zoom pill: an 80px fixed input plus padding took ~113px of a
375px bar, more than the home icon, the mode toggle and the bell together. "100"
fits in about half of that, and the pill may now shrink; the bell and the avatar
never shrink, being what the user came for. `html { overflow-x: hidden }` on a
small screen is the guarantee that a future item, a long translation or a custom
logo cannot bring the sideways scroll back.
tests/mobileAllBoardsFit.test.cjs pins both: the handle width is reserved once
and dropped entirely when there is no handle, and the bar's widest item can give
way while the page cannot scroll sideways.
Thanks to xet7 !
Playwright caught this on all three browsers: "Version page shows Reactivity
mode" got All Boards instead. Both old URLs are panes of Admin Panel / Settings
now, and both redirected with FlowRouter.go('setting') called from INSIDE
triggersEnter. A trigger runs while its own route is still entering, and a go()
from there is swallowed - the action() renders nothing, so whatever page the
browser was already showing simply stayed. A bookmark to either URL landed
nowhere.
A trigger redirects with the `redirect` it is HANDED, which is the form the
redirections table at the bottom of config/router.js has always used.
Each URL now also asks for the pane it used to be a page of - Version for
/information, Translation for /translation - so the bookmark lands where it
pointed rather than on the default pane. The request is consumed once, so a
later visit to /setting opens on the default, and it marks the open pane as
decided so the site-admin autorun does not undo it a moment later.
tests/adminOldUrlRedirect.test.cjs pins the redirect form (and that no
FlowRouter.go() creeps back in), the pane each URL asks for, and that the
ReactiveVars it sets are created before it runs.
Thanks to xet7 !
The reporter says the board list still cannot be scrolled on a phone at v10.37,
after the layout fix. There is a reason that fix cannot have covered it, and it is
not visible in the Playwright run: a fixed test viewport has no browser toolbar.
The page sizes its scroll containers as `100vh` minus a bit - the wrapper, the
left menu, the board list, and the mobile body and content area. On a phone
`100vh` is deliberately the LARGEST the viewport can be: the height with the
browser's toolbars hidden. With the toolbar showing, every one of those boxes
reaches under it - and the wrapper is `overflow: hidden`, so what is underneath
cannot be scrolled to at all. The bottom of the board list is simply unreachable,
which looks exactly like "the list does not scroll".
Each of those rules now states the `vh` value first, as the fallback, and the
same value in `dvh` - the viewport as it is at that moment - immediately after. A
browser that understands `dvh` gets the real height; one that does not behaves
exactly as before.
The two scrollers also declare `overscroll-behavior: contain` and
`touch-action: pan-y`, so a vertical swipe is given to them rather than to the
page behind or to another gesture.
NOT verified here: there is no phone in this environment, and no browser toolbar
in Playwright, so this is reasoned from the source and from how the mobile
viewport units are defined. What IS verified is that nothing else in the page's
touch handling blocks the scroll: with drag handles on - which a touch screen
turns on - a board drag may only begin on the handle, the tile itself stays free,
and the touch drag-and-drop bridge honours that cancellation.
tests/mobileViewportHeight.test.cjs pins all of it, including that the `vh`
fallback is declared before the `dvh` value.
Thanks to mimZD and xet7 !
Fixes#6488,
Opening a card APPENDED it to the open-cards list, so the card that was already
open stayed open behind the new one - which the reporter saw as soon as the new
card was dragged: the old one was still sitting there. Clicking another card means
"show me that card", not "show me both".
A click now opens THAT card and closes the previous one. Both ways of opening a
card - the minicard and its title - go through one helper, so neither path can
drift from the other again.
Keeping several cards open at the same time is still possible, as the per-user
setting it should always have been: Member Settings / "Open many cards at once",
off by default, stored as `profile.openManyCardsAtOnce` and toggled by a server
method like the settings beside it. A reader who is not logged in gets the
default rather than an error.
tests/openManyCardsAtOnce.test.cjs replays the decision in both states and guards
the wiring: schema, helper, method, menu entry, check mark and translation.
Thanks to mimZD and xet7 !
Fixes#6531,
The board export REST endpoints look a user up by the login token in
`?authToken=`. A token that matches nothing makes that lookup answer `undefined`,
and the next line dereferenced it:
user = await ReactiveCache.getUser({ 'services.resume.loginTokens.hashedToken': … });
adminId = user._id.toString(); // TypeError on an unknown token
The handlers are async and had no try/catch, so the TypeError escaped as an
unhandled promise rejection - which this app turns into a full process crash (the
note in server/ldapGroupSync.js explains why). One crafted GET against a private
board id took the server down for every user. Reachable by anyone who can obtain a
private board id, which on an open-registration instance means anyone at all.
It was an incomplete fix: models/exportPDF.js and models/exportExcelCard.js
already had the `if (!user)` guard; three handlers in models/export.js and one in
models/exportExcel.js were missed.
Fixed on both levels:
* Every token lookup in the export models is now followed by the guard - 401
"Invalid token" and return - including the two handlers that did not crash
because they hand the user to canExport() instead of dereferencing it. One
rule for every lookup is what stops the next handler being the missed one.
* Every export route body is wrapped in safeRoute() (server/apiMiddleware.js),
which awaits the handler, answers 500 once and logs the request that failed.
A throw from any other cause is now one broken request instead of an outage.
tests/exportTokenGuard.test.cjs does not check four places by hand: it finds every
token lookup in the export models and requires a guard on each, that nothing
dereferences the user before it, that every route is wrapped, and that the two
handlers which were already guarded stay guarded.
Thanks to laijunyue for the coordinated disclosure, and xet7 !
An entry had grown into a paragraph - one ran to 1,600 characters - so the file
could no longer be read as what it is: a list of what changed, by version. That is
what the reporter asked for: "i just wanna see title of changes (fixes, new
feature, improves, ...) by the time and version, as changelog was before".
Every entry is now
- <one-line title> ([<short hash>](https://github.com/wekan/wekan/commit/<hash>)).
Thanks to ...
with the long story left where it belongs: in the commit message the link points
at. 3,000 entries were rewritten across the whole file, every commit link shows and
uses the 9-character hash instead of a description or "merge commit", 61 bare long
URLs became short links, and everything is wrapped at 80 columns - a line carrying
a link excepted.
A few malformed entries surfaced and are repaired on the way: a stray `](url)`
whose opening bracket was never written, a doubled `/commit/commit/`, a link with
no hash at all, and one URL missing its repository name.
CLAUDE.md now states the rules - title not story, hash as link text, never a long
URL as visible text, 80 columns - and tests/changelogFormat.test.cjs checks the
file against them, strictly for the Upcoming section.
Thanks to mimZD and xet7 !
Fixes#6524,
Caught by the newest Playwright run: the Version page test failed in all three
browsers, and the page it got was Visibility.
The multitenancy work decided the opening pane at onCreated:
const siteAdmin = tenantAdmin.isSiteAdmin(ReactiveCache.getCurrentUser());
this.versionSetting = new ReactiveVar(siteAdmin);
At onCreated the user document has often not arrived yet, so getCurrentUser() is
null, "is this the site admin?" is false for EVERYONE for that moment, and the page
opened on the pane meant for an Organization's own admin - for the site admin too.
Admin Panel / People had the same shape and could open on the wrong pane the same
way.
Both open on what they always opened on again - Version and Login - and the
exception for an Organization's own admin is applied in an autorun, once, when the
user is actually known.
Thanks to xet7 !
The app-wide rule that hides a native checkbox hides it in THREE ways at once:
display, visibility, and `inset-inline-start: -9999px`. The Admin Panel rule undid
the first two, so the box was on screen - 9999px to the side. Unchecked it was
simply not there; checked it appeared, because the checked state sets its own -3px
offset. That is exactly what "only the checked state is visible" was, in the
S3/MinIO, Azure and GCS panes and everywhere else a native checkbox is used.
`inset-inline-start: auto` (and `top: auto`) undoes the third.
The test now reads the hiding rule and requires the Admin Panel to undo every
property it hides with, rather than a list written by hand - so a fourth way of
hiding one would fail here instead of on screen.
Thanks to xet7 !
TypeError: can't access property "set", tpl.loading is undefined
on every click in the Login pane - Forgot Password, Self-Registration, Username
Change, Self delete user account, Display Authentication Method - and on the
E-mail pane's Save.
Blaze hands an event handler the instance of the template the handler is
REGISTERED on. When those handlers moved onto Template.general and Template.email -
which they had to, because Admin Panel / People renders those panes now - the
state they poke, `loading`, stayed behind on Template.setting. So the first line of
each handler threw, the setting was never written, and nothing on screen said so.
Both templates create their own `loading` now.
tests/adminTemplateState.test.cjs walks the Admin Panel components and fails when
an events or helpers block reads `tpl.<name>` that its own template never created,
so moving a handler without its state cannot pass again.
Thanks to xet7 !
"Support page enabled" animated to checked and fell back to unchecked. The reason
was not the checkbox: Admin Panel / Settings / Visibility draws it from
`currentSetting.supportPageEnabled`, and that field was not in the `setting`
publication. On the client it was therefore always undefined - the box drew
unchecked, ticking it wrote the setting to the server, and the next re-render drew
it unchecked again. The setting was saved; the checkbox said it was not.
Announcement's checkbox never had the problem because it reads the Announcements
collection, which is published whole - which is exactly why that one worked and
the Settings-backed ones did not.
Now published, and each of them is a control that was unusable: supportPageEnabled,
supportPagePublic, supportTitle, supportPageText, supportPopupText,
hideBoardActivitiesOnAllBoards (Visibility / All Boards) and
boardMembersFromSameOrgOnly / boardMembersFromSameTeamOnly (People / Organizations
and Teams). The SMTP settings stay out: they carry a password and have their own
admin-gated publication.
tests/settingPublishedFields.test.cjs walks every `currentSetting.<field>` in every
client template and fails when the publication does not carry it, so the next field
added to a pane cannot silently render as undefined.
Thanks to xet7 !
The material declarations were right, but one thing still fought them: forms.css
styles `input:not([type=file])` as a form FIELD - grey background, 6px radius,
padding, bottom margin, and `min-height: 41px`. Everything else was overridden;
the height floor was not, so a 13px box was drawn as a tall rectangle and the tick
it turns into was stretched with it. That is why the checked state looked roughly
right and the unchecked one did not, in Attachments / Limits / Avatars, in the
S3/MinIO, Azure and GCS storage panes, and everywhere else a native checkbox is
used.
`min-height: 0` (and `min-width: 0`) undoes it - the same reset
`input[type="radio"]` does a few lines below that rule in forms.css, for exactly
this reason.
The test now asserts every part of the form-field styling is undone, naming the
41px floor, so this cannot come back unnoticed.
Thanks to xet7 !
Day of week was a text field. It only ever accepted an English day name, typed
exactly right, from an admin reading a page in their own language - and nothing
said so. It is seven buttons now, each labelled in the reader's language.
Day of month was a number spinner: 27 clicks to reach the end of the month, and no
sign that the 29th to the 31st are not offered at all - a schedule there would
skip February. It is 28 buttons, one per date.
What is STORED is unchanged: the English day name and the number, because that is
what the cron sentence is built from (models/lib/backupPaths.js scheduleText).
Only the labels are translated. The chosen one is filled with the theme colour,
the way the selected left-menu entry is, and the rows wrap rather than squeeze.
The choice is template state now, seeded from the saved schedule when it arrives -
and not overwritten by it once the admin has picked something.
Thanks to xet7 !
"Attachments, Avatars, Data (text)" already draw as the Admin Panel's checkbox -
the plain square when off, the green tick when on, animated between, like
Announcement's "Active System-Wide Announcement" - since the checkbox style was
made the material one for every native checkbox in the panel.
What they lacked was layout: three inline labels, so a label could wrap away from
its own checkbox, and the box shifts a few pixels as it turns into the tick, which
unaligned text follows. They are one flex row now, each label holding its box and
its words together.
Thanks to xet7 !
The Save inside the New and Edit popups for Translation, User, Organization and
Team is an `input[type=submit].primary.wide` in a flex `.buttonsContainer` - and
`.wide` never reached it, because the rule for it in forms.css is written as a
DESCENDANT selector, `input[type="submit"] .wide`, which an input can never match.
So those Saves were the right colour but a different, cramped size from the Save
in a pane (People / Login, People / E-mail, Visibility).
All eight popups are now listed with the panes' own Save declarations - the theme
accent, the same padding, weight and states - and each Save takes its row, which
is what `.wide` was for. The popups are named one by one on purpose:
`.buttonsContainer` is board-sidebar and member-menu markup too, and those are not
Admin Panel buttons.
The test walks the Admin Panel templates and fails if a popup with a Save is not
in that list, so the next popup added cannot quietly get a plain button.
Thanks to xet7 !
The last Yes/No pair in the pane. Like the four in All Boards: Hide above it, the
setting is on or off, so it is one checkbox in the Admin Panel's own style -
square when off, green tick when on, animated between - and the Logo section's
Save writes the tick, skipping it when the checkbox is not on screen.
Visibility has no radio pairs left.
Thanks to xet7 !
Public boards, Board activities, Card counter list and Board member list were
Yes/No radio pairs. Each of them is on or off, and the group's own title already
says what turning one on means - "All Boards: Hide …" - so each is one checkbox
now: the same checkbox as everywhere else in the Admin Panel, with the plain grey
square when off, the green tick when on, and the animation between.
The section's Save writes the ticks the way it read the radios, and still skips a
setting whose checkbox is not on screen rather than writing it as false - the
guard that keeps a hidden field from being blanked, which is what these settings'
own regression test is about.
Thanks to xet7 !
The first attempt drew the checkmark with a pseudo-element over the box. That got
the checked state right and lost the other two thirds of the checkbox: the plain
grey square when unchecked, and the 0.2s morph between them that Announcement's
"Active System-Wide Announcement" checkbox has.
The rules are now `.materialCheckBox` and `.materialCheckBox.is-checked` applied to
the input itself - the same square, the same morph into the same green tick, the
same transition - with `appearance: none` as the only addition, to take the
browser's own rendering out of it. A native Admin Panel checkbox and a WeKan one
are now the same checkbox in every state.
The test compares them declaration by declaration against forms.css, so a change
to the material checkbox that is not carried over here fails rather than quietly
leaving the two different again.
Thanks to xet7 !
A pane's Save is a `button.primary`, which forms.css themes. The Save inside the
Admin Panel edit popups (Edit User, Edit Organization, Edit Team) is an
`input[type=submit].primary.wide` in a flex row - and `.wide` never reached it,
because the rule for it in forms.css is written as a DESCENDANT selector,
`input[type="submit"] .wide`, which an input can never match. So the popups' Save
was the same colour but a different, cramped size.
Both are listed with the same declarations now - the theme accent, the same
padding, weight and states - so they cannot drift apart again, and the popups'
Save takes its row, which is what `.wide` was for.
Also: a checkbox written as `label > input + text` (Attachments / Limits /
Avatars, and the Backup checkboxes) gets the gap between box and words that the
.materialCheckBox markup gets from its own layout.
Thanks to xet7 !
WeKan hides the native checkbox app-wide and draws its own square with a green
tick - `.materialCheckBox`, which is what Admin Panel / Settings / Announcement
shows for "Active System-Wide Announcement". But several Admin Panel panes use a
real <input type="checkbox">: the storage Read toggles, the Organizations and
Teams feature columns, the Backup checkboxes, the Problems summary. Those were
either invisible, because nothing re-enabled them, or re-enabled pane by pane and
then drawn by the BROWSER - on Ubuntu a big orange box that ignored the chosen
theme entirely (orange under clearblue), at a different size in every pane.
The Admin Panel now styles them itself: `appearance: none` takes the browser's
rendering out of it, and the tick is drawn the same way .materialCheckBox draws
it - two borders of a rotated box, in the same green - so a native checkbox and a
WeKan one are the same checkbox to look at. Grey icons, disabled and keyboard
focus are handled with it, and the panes no longer each re-enable and re-size
their own.
Admin Panel / People / E-mail / Allow Email Change is one such checkbox now
instead of a Yes/No radio pair: the setting is on or off. Save below writes it as
it wrote the radios, and only when the checkbox is on screen.
Thanks to xet7 !
The twelve strings the multitenancy and site-theme work added - the Organization's
domains and their description, the domain-taken error, the Organization admins
popup and its description, the backup scope and its description, and the line that
says a site admin's theme applies to all tenants - are translated into all 142
languages, using each language's existing WeKan terminology for Organization,
backup, admin and theme.
Nothing existing was touched: every value was written through
releases/translations/fill_translations.py --apply, which only ever fills a
placeholder (a key that is missing, or still equal to the English source), so a
human translation can never be overwritten. Key order and the 2-space indent are
preserved, and none of these are pushed to Transifex, where a real translation of
them can replace them at any time.
Thanks to xet7 !
It used to be filled with `--theme-accent`, one flat colour. That is close for most
themes and wrong for clearblue, whose bar is a colour SLIDE - a gradient no single
accent value can express.
Every theme's own `#header` rule in boardColors.css now names the selected row as
well, so the two are painted by exactly the same declaration, theme by theme: a
flat colour stays flat, a gradient stays a gradient, and adding a theme cannot make
them drift apart. The `--theme-accent` rule stays as the answer for an instance
with no theme at all.
tests/themeAccents.test.cjs asserts every allowed theme paints the row, and that
the selector is only ever added to a rule that also paints the header - never to a
copy of the colour.
Thanks to xet7 !
Choosing a named theme recoloured the header - which has a
`.board-color-<name>#header` rule of its own - and left everything that reads the
`--theme-accent` CSS variable on the stock blue: the Admin Panel's selected
left-menu row, its pane buttons, every Save button, the table-page controls and
the popup header. That variable was only ever set when a user picked a CUSTOM
colour for a flat/clear theme.
models/lib/themeAccents.js now maps every allowed theme to the colour that theme
paints its header with, and globalThemeColor.js publishes it as --theme-accent
whichever theme is in force: the user's own override, the board's colour, or the
site theme. A custom colour still wins over it, and the has-custom-theme-* classes
stay tied to a custom colour - they exist to override a named theme's own header
rule, which a named theme must not do to itself.
tests/themeAccents.test.cjs parses boardColors.css and fails if the map and the
stylesheet ever disagree, so a theme cannot be added in CSS alone and quietly fall
back to blue.
The Admin Panel edit popups (Edit User, Edit Organization, Edit Team) also got
their layout fixed: they are centred on the window rather than positioned from the
table row that opened them - which pushed their right-hand side, and the Save
button, off the screen - and their fields lay out in as many columns as the window
has room for, so a long form no longer has to be scrolled to reach Save. No popup
can be wider than the window any more.
And two smaller things in the Admin Panel: the Wait Spinner setting shows a live
preview of the spinner beside its dropdown, which wraps below the dropdown when
there is not enough room; and the Translation table's New column moved to the
left, where every other Admin Panel table page has it.
Thanks to xet7 !
Admin Panel / Settings / Visibility / Change color set the site theme and the
buttons picked it up - but both top bars stayed on the default colour, while a
user's own override still coloured them.
The reason: #header, #header-quick-access and .board-wrapper each spelled the
order of themes out in the template - the user's own override, else the board's
colour - so nothing there read the site theme (docs/Design/Page/Theme.md, layer 2)
at all. Only the <body> autorun knew about it, which is why the buttons changed
and the chrome did not.
One Blaze helper, themeColorClass, now answers for all three, in the one order:
the user's own override, then the board's own colour on a board page, then the
site theme. The templates read that single answer instead of re-deriving part of
the order, so the layers cannot drift apart again.
tests/globalThemeColor.test.cjs asserts both halves: that the three places use
the helper, and that the helper keeps the order.
Thanks to xet7 !
Every app file is an ES module in Meteor, so `module.exports = {…}` in one of
them throws the moment the CLIENT bundle loads it:
Uncaught Error: ES Modules may not assign module.exports or exports.*,
Use ESM export syntax, instead: ./models/lib/tenantAdmin.js
and because it throws, every module after it in the client graph never runs -
models/users.js imports tenantAdmin, so the whole client went down with it.
models/lib/tenants.js, tenantAdmin.js and tenantBackup.js now export with ESM
syntax, and every importer uses import instead of require(). The .cjs unit tests
load them with a dynamic import(), the way tests/cardUrl.test.cjs already loads
its module.
tests/tenantWiring.test.cjs guards both halves, so the same crash cannot come
back quietly.
Thanks to xet7 !
Implements option D of docs/Design/Multitenancy/Multitenancy.md, which that
document now describes as shipped.
An Organization may claim hostnames (Admin Panel / People / Organizations ->
Edit), carry its own branding - product name, logos, help link, legal notice and
theme colour - and have its own Organization admins, appointed from the row's
"..." menu. The request's host picks the Organization; its branding replaces the
instance branding for that request, and the client bundle that host serves points
its DDP connection back at that host instead of at the one ROOT_URL.
An Organization admin administers their own Organization and nothing else: its
people, its Organizations row, its theme colour and its backups. They can never
grant the site-wide Admin flag, never manage a site admin, and never see another
Organization's people or archives.
Per-tenant backup and restore is one new control in Admin Panel / Attachments /
Backup - Scope. An Organization's archive holds its boards and everything on them
plus the attachments those boards use, and no accounts, no instance settings and
no org/team documents, because those are shared. A restore may only write to
boards that Organization owns: the board ids are the intersection of what the
archive claims with what the Organization really owns, every document is checked
against that, and "replace all" replaces that Organization's documents rather
than everyone's.
Admin Panel / Settings / Visibility gains a Change color section above Logo: the
site theme, rendered by the SAME shared picker as Board Settings and Member
Settings - one template for all three, the way one shared table page serves every
table. Its design is the new docs/Design/Page/Theme.md. The order of themes is
WeKan's default theme, then the site theme (an Organization's own value on its own
hosts), then a user's own override; a board's own colour still owns the board page.
All of it is OFF unless the server is started with MULTITENANCY=true (plus
MULTITENANCY_TRUST_PROXY_HOST=true when a trusted proxy sets X-Forwarded-Host), so
an instance that has never heard of tenants answers exactly as before. One WeKan
server per customer remains the supported topology for customers who must not
share a process, and the design says plainly what this does NOT isolate.
The decisions are three pure modules - models/lib/tenants.js, tenantAdmin.js and
tenantBackup.js - so the same rules run on the client, on the server and in the
tests. Four new suites pin the separation rather than the plumbing: forged Host
headers, cross-tenant queries, privilege escalation and cross-tenant restores.
Thanks to xet7 !
The pane only had content inside a Sandstorm grain: the one-time MongoDB 3 ->
FerretDB migration status and a button that DELETED the raw MongoDB 3 database
files to reclaim grain disk. Compacting the MongoDB database frees that space as
well, so deleting raw database files is not something WeKan needs to offer.
The left-menu entry, the pane template, the helpers, the template state and the
click handler are commented out rather than deleted, so nothing of it runs and
the grain migration report can be brought back if it is ever wanted. The server
methods it called are left in place.
Everything else keeps working: the storages and their statistics, moving
attachments between storages, the MongoDB <-> FerretDB database migration, and
Backup. The grain's own migration, which runs in sandstorm-src/start.js before
the app boots, is unchanged.
Thanks to xet7 !
14 tests failed in every browser in the newest run (../log/2026-07-26_05-22-11),
all on one selector:
TimeoutError: locator.waitFor: Timeout 15000ms exceeded.
- waiting for locator('.js-people-menu') to be visible
`.js-people-menu` and `.js-templates-menu` do not exist any more. Admin Panel /
People renders the ONE shared left menu now, which is `a.js-left-menu-item(
class="{{jsClass}}" data-id="{{id}}")` - and People passes no jsClass, so its
entries have no per-page class at all. data-id is what the design says a page's
click handler reads (docs/Design/Page/Left-Menu.md), so that is what the tests
address the entry by: it cannot be removed by a conversion the way a per-page
class was.
The same conversion had left three other groups of selectors behind:
* Admin Panel / Problems' report entries - a.js-report-files / -rules / -boards
/ -cards / -impersonation - are the shared menu too, so they become
[data-id="report-files"] and so on;
* every report's own search input (input.js-rules-search-input and its four
siblings) is the shared controls row's input.js-table-page-search, and
.admin-report-pagination is .table-page-pagination - one shared table page for
all of them (docs/Design/Page/Table.md). The Files test also asserts the old
input is GONE, beside the Search button it already asserted;
* the People pager in the page object, button.js-people-next-page /
-prev-page, is the shared button.js-table-page-next / -prev.
The four reports that must not hang on FerretDB were proved ready by their own
search input rendering; with one shared input for every report that no longer
distinguishes them, so each is now proved by the shared input AND the pane title
naming that report.
Not run here: this sandbox has no node, so the suite has to be run on a machine
that has one. Every selector introduced was checked to exist in the app, and the
four report titles were checked against en.i18n.json.
Thanks to xet7 !
One MongoDB server holding one database per tenant - which is the shipped
docker-compose-multitenancy.yml unchanged. Only the Node side differs from the
baseline: one process opens all of those databases instead of n processes opening
one each. And because each driver takes a full connection URL, one server with
many databases is the common case rather than a requirement - a large tenant can
be moved to its own mongod without the others noticing.
Thanks to xet7 !
docs/Design/Multitenancy/Multitenancy.md. The shipped topology
(docs/Platforms/FOSS/Docker/Meteor3/) runs one WeKan Node.js server per customer:
one ROOT_URL, one database, one uws.port and one upgrade each. This designs the
alternatives to that - one server serving many domains - and says what each one
would cost, from WeKan's own code rather than in the abstract.
Six things one process must solve, with the Meteor 3 API for each: resolving the
tenant from the Host header (Meteor.onConnection gives httpHeaders, cookies
excluded; behind a proxy it is X-Forwarded-Host, and a forgeable header is a data
leak); the client bundle's baked-in ROOT_URL (WebApp.addRuntimeConfigHook rewrites
__meteor_runtime_config__ per request - and was broken in Meteor 3.0 alpha/beta/rc
until meteor#13156, which any use of it has to state a minimum version for);
server-side absolute URLs (Meteor.absoluteUrl's {rootUrl} override, and the handful
of WeKan call sites - universalUrlGenerator.js already builds relative URLs and is
the model); the data itself; accounts; and the eight settings singletons plus the
~102 process.env reads that are per-process today.
Four alternatives, compared in a table: one process per tenant (today), one
database with a tenant field (mizzao:partitioner from Meteor-Community-Packages,
Meteor 3 async), a database per tenant in one process (MongoInternals.
RemoteCollectionDriver), and Organizations as tenants - which is the one WeKan
already half has, since orgs, teams, their membership and the same-Organization /
same-Team board restriction all exist and are enforced server-side.
The recommendation is to keep one process per tenant as the supported topology and
reach for Organizations when the tenants are groups of one organisation: the other
two trade an operational cost that is merely tedious for a failure mode - a missed
selector on one of 46 collections or 66 publications - that is silent
cross-tenant disclosure. With, if it is ever attempted, the order that keeps it
honest: resolve the tenant once, do the settings singletons first because they
prove the pattern end to end, content collections only then with a test per
publication, and accounts last or not at all.
Linked from the two guides it is about and from the Scaling section of
docs/README.md.
Thanks to xet7 !
The section had grown one bullet at a time, so it read in the order things were
written rather than in the order CLAUDE.md asks for, and three threads of work were
missing from it entirely. Checked against `git log v10.37..HEAD`, the merged pull
requests and the dependabot bumps.
Order now: the CRITICAL SECURITY ISSUE (ZipBleed), then the Admin Panel
reorganisation, then the dependency updates, then the bug fixes, then the
developer-facing changes, the documentation and the translations - each later
subsection starting with a lowercase "and" so the headers read as one sentence.
Added, because no bullet covered them:
* the Settings reorganisation itself - Layout becoming PWA, the Accounts pane
going away, Registration being renamed Login, "don't show board activities"
becoming one global setting instead of a write over every board, and the
branding, Wait Spinner, Support, help link and legal notice moving to the panes
they belong to;
* the four People panes rendering through the shared table page, with the row and
header slots and the controls-row features that came from that pane;
* the shared left menu on every Admin Panel page, the selected entry matching the
selected tab above it, and the page-title bars going away;
* the five dependency updates merged since v10.37 - @aws-sdk/client-s3, unzipper,
bson, @playwright/test and docker/login-action - each with its pull request and
merge commit, thanked to dependabot;
* the Sign In / Register scrollable space;
* the left-menu design and its test suite, beside the table page's.
Two bullets moved to the group they belong to: the E-mail pane saving neither of
its settings is a bug fix, and every .jade template being compiled by a test is
developer-facing.
Thanks to xet7 !
vl-SS 93 strings from nl: Flemish and Dutch share these UI words, and its own
file already used Bord / Kaart / Lijst. What is left is what Dutch spells
like English too.
vo 51 in Volapük, following the file's own vocabulary (tab, kad, lised,
svimavög)
tlh 54 in Klingon, following the file's own vocabulary (raS, nav, tetlh, He)
The long prose strings of vo and tlh - the recovery-report description and the
problems-in-progress help - are deliberately left in English: composing new
sentences in either language with any confidence is beyond what can be verified
here, and an invented sentence is worse than the English source that at least
reads correctly.
Thanks to xet7 !
wa 49 in Walloon, propagated to wa-RR
fy 95 in Frisian, propagated to fy-NL - one of the two longest lists that were
left, now down to what Frisian spells like English
Thanks to xet7 !
hy 45 in Armenian
af 46 in Afrikaans, propagated to af_ZA
tk 57 in Turkmen (tk_TM)
Each is the same set: the Admin Panel toggles, the recovery report, the problems
status, the broken-card repair, the CPU figures, board status, the import timeout
and the map-to-existing-user dialog, in that language's own kanban words.
Thanks to xet7 !
ug 49 in Uyghur: the Admin Panel set, recovery, board status, storage, CPU
zu 53 in Zulu, propagated to zu-ZA
be 75 in Belarusian: the same set plus the whole search-predicate vocabulary
(archived, open, ended, overdue, week/month/quarter/year, assignee, member,
public/private, selector, projection)
xh 50 in Xhosa
Thanks to xet7 !
68 strings in Khmer: the Admin Panel set, the Version page fields (database commit,
FerretDB version, reactivity mode, OS architecture / free memory / load average),
board status, the date formats, the Azure and GCS fields, backup, recovery,
problems, repair and CPU. km-KH took them afterwards; km_KH already had its own.
Thanks to xet7 !
gu-IN 74: theme and font, the date formats, board status, the Azure/GCS fields,
backup, avatars, recovery, problems, repair and CPU
or_IN 50: the Admin Panel set, recovery, board status, the storage fields
uz 49, propagated to uz-AR/uz-LA/uz-UZ
az 49, propagated to az-AZ/az-LA
Thanks to xet7 !
sw 50: the Admin Panel set, recovery, problems, repair, CPU and board status,
plus the colour names Swahili has its own words for
nl 49: sjablonen, checklist, lettertype, stickers, the OS/FerretDB fields of the
Version page, the S3 and Azure fields, repository, logboek
yo 39 and ig 41: the same core set - the Admin Panel toggles, recovery, repair,
board status and CPU - in Yoruba and Igbo
nl-NL took nl's words afterwards.
Thanks to xet7 !
de the last few that differ in German (Beginn, Rechner, Detail, the storage
descriptions) - the rest of its list is words German spells as English
it 47: lista di controllo, carattere, adesivi, assegnatari, archiviazione, the
cron/backup/server vocabulary
th 83: the whole Version page (Node heap, Mongo sessions, OS arch), the S3 and
Azure fields, board status, support, accessibility, the date formats
ta 48: the Admin Panel set, recovery, problems, repair, CPU and board status
te 48 (te-IN): the same set in Telugu
pa 46: the same set in Punjabi
Thanks to xet7 !
One language at a time, in order of how widely it is spoken, filling everything
that is genuinely translatable and leaving what is identical in that language
(the tooling ignores a value equal to the English source anyway).
zh-CN/zh-TW the S3 fields, the date formats, the pangram, FerretDB commit, cron
hi board status, card loading, statistics, the date formats, pangram
es checklist, stickers, the Azure/GCS descriptions, bucket, selector
ar the date formats, selector/projection, storage descriptions, cron
fr the two storage descriptions - everything else left is a word French
spells the same as English
pt / pt-BR board status, statistics, website, card loading, storage descriptions
id 67 strings: theme and font, the search predicates, board status, the
S3 fields, backup, support, the file/log/server vocabulary
ms 73 strings: the whole Admin Panel set, recovery, problems, repair and
CPU, plus the predicates, board status and the storage descriptions
Their regional variants were refreshed from each base afterwards - zh-Hans/zh-Hant/
zh-HK/zh_SG/zh-GB/cmn/wuu-Hans/yue_CN, hi-IN, the eight es-*, ar-DZ/ar-EG/ary,
fr-CH/fr-FR, pt-PT, ms-MY.
Thanks to xet7 !
Filled by hand, no service: sk, sl, hr, sr, lt, lv, et-EE, eu, gl, th - the same
Admin Panel, recovery, problems, repair and CPU strings as the previous batch, in
each language's own kanban terminology (hr ploča/kartica, sr табла/картица, lt
lenta/kortelė, lv dēlis/kartīte, et tahvel/kaart, eu arbel/txartel, gl
taboleiro/tarxeta, th บอร์ด/การ์ด).
And a variant pass: 64 regional files - de-AT/de-CH/de_DE, fr-CH/fr-FR, es-AR/es-CL/
es-CO/es-LA/es-MX/es-PE/es-PY, pt-PT, ru-RU/ru-UA, uk-UA, zh-Hans/zh-Hant/zh-HK/
zh_SG/zh/cmn/wuu-Hans/yue_CN, ja-HI, ko-KR, ar-DZ/ar-EG, ca_ES/ca@valencia, cs-CZ,
el-GR, fa-IR, he-IL, hi-IN, nl-NL, pl-PL, ro-RO, sl_SI, vi-VN, wa-RR, ve-CC/ve-PP
and the rest - take their base language's translation for every string they had not
translated themselves. 1,903 strings, none of them a machine translation: they are
the same language's own words, and a variant that HAD its own translation keeps it.
Thanks to xet7 !
The strings that were untranslated everywhere - Transifex and git - are the ones
this repo fills directly, with the language's own existing translations and its
kanban terminology as the reference, and no external translation service, API or
password anywhere near it (releases/translations/fill-translations.mjs, and the
CLAUDE.md policy above it).
Filled for: fi, sv, da, nb, de, nl, fr, es, pt, pt-BR, it, ca, ro, cs, pl, hu, ru,
uk, bg, el, tr, ar, he, fa, hi, id, vi, ja, ko, zh-CN, zh-TW - 1,127 strings. Most
of them are today's Admin Panel work (the Login: Allow group, All Boards: Hide, the
two board-member restrictions, the invite-domain field, Visibility) plus the
recovery report, the problems status, the broken-card repair, the CPU figures, the
import timeout and the map-to-existing-user dialog.
Terminology follows each file: fi taulu/kortti/lista, de Board/Karte/Liste, fr
tableau/carte/liste, es tablero/tarjeta, pt-BR quadro/cartão/raia vs pt
quadro/cartão/pista, it bacheca/scheda, nl bord/kaart, ru доска/карточка, pl
tablica/karta, cs tablo/karta, tr pano/kart, uk дошка/картка, zh 看板/卡片, ja
ボード/カード, ko 보드/카드, ar لوحة/بطاقة, he לוח/כרטיס, fa تخته/کارت, hi बोर्ड/कार्ड.
Nothing here can overwrite a human translation: a key is filled only while it is a
placeholder (missing, or equal to the English source), and the apply step reports
and skips every key that already holds a translation - 150 of them across this
batch. Filled strings stay LOCAL and are never pushed to Transifex as human ones.
releases/translations/fill_translations.py is added beside the .mjs: the same rules
in Python, because the sandbox this ran in has no node runtime. Either can be used;
they agree on what a placeholder is, on the en.i18n.json key order and on the
2-space indent.
111 languages still have untranslated strings (14,112 placeholders, of which a
large part - numbers, "?", "/", LDAP, OAuth2, GridFS, S3/MinIO, Arial, the
__board__ patterns - are identical in every language and can never be "filled").
Thanks to xet7 !
Both remaining documentation entries of CHANGELOG's TODO Later, done together
because they are the same sweep.
A menu path is a docs path now. Admin Panel / Settings / Visibility is
docs/Features/Admin-Panel/Settings/Visibility.md; Admin Panel / People / Teams is
People/Teams.md; and each of the four sections has an index listing its panes in
menu order. Before this a reader could not map what they were looking at to a file:
the folder held Admin-Panel.md plus two loose pages, and the prose still described
panes that had moved or gone.
What the prose now says, and did not:
* Version is a Settings pane and the one that opens with the Admin Panel; the
Info tab is gone and /information redirects.
* Visibility is four groups with a Save each - All Boards: Hide, URL, Product
name, Logo - and absorbed Allow-private-boards-only.md and Custom-Logo.md,
which were separate pages for two of its settings.
* Layout is PWA, and holds only the PWA settings: everything else in it moved to
Visibility. Wait-Spinners.md pointed at Layout and now points at the group it
is in.
* Registration is People / Login, one "Login: Allow" group of checkboxes, and
the Accounts pane is gone - allow e-mail change is in People / E-mail, username
change and self delete in People / Login.
* The e-mail domain field decides who may INVITE while self-registration is off,
not who may sign in.
* The board-member restriction is two checkboxes, in Organizations and in Teams.
* The Features tab is gone: its panes are the Settings group of Problems, whose
menu is two named groups. Undo.md, which plans a Features / Delete pane, says
so where it plans it.
* Attachments has a page per menu entry, Backup first, and Problems' index
describes today's two groups.
Every link into the moved pages was updated - docs/README.md, Features.md,
Boards.md, Templates.md, Status.md, Members.md - and every relative link inside the
Admin Panel tree resolves.
wekan.fi: the Admin Panel row of docs/index.html described the old panes (Features,
Info, Translation as tabs; "registration, accounts, table visibility, layout"), the
Registration control row named settings that have moved, and install/index.html sent
readers to Settings/Layout for the logo. Those are edited in ../w/wekan.fi and left
uncommitted there, as that repository is not this one.
Thanks to xet7 !
"Add board members only from the same Organization or Team" was one checkbox in the
Login pane - which is where neither of the two things it restricts lives. It is two
checkboxes now, each in the pane it is about:
Admin Panel / People / Organizations [_] Add board members only from the same
Organization
Admin Panel / People / Teams [_] Add board members only from the same Team
A candidate may be added to a board when they share at least one ENABLED kind with
whoever adds them: an Organization when the first is on, a Team when the second is.
With both on that is "an Organization OR a Team" - exactly the rule the single
setting had - so an install that has the old field and neither new one is migrated
to both on first start, and nobody's restriction changes by upgrading. Ticking only
one is the new, narrower choice that was not expressible before.
models/settings.js boardMembersFromSameOrgOnly, boardMembersFromSameTeamOnly
server/models/settings.js the startup migration from the old single field
server/lib/orgTeamRestriction.js
boardMemberRestriction(setting) reads the pair - and
still reads the old field, so an install behaves the
same before the migration runs; canAddUserToBoard()
takes a flag per kind (the old restrictEnabled still
means both)
models/users.js sharesOrgWith / sharesTeamWith, and
sharesRestrictedOrgOrTeamWith(user, restriction)
Enforced in the same three places as before - inviteUserToBoard, the user-search
typeahead that must not offer what the server would reject, and the imported-user
reconciliation - so the two settings cannot drift apart from what the UI says.
Thanks to xet7 !
The pane mixed two opposite ways of saying the same kind of thing: "Disable Forgot
Password" and "Disable Self-Registration" as checkboxes where TICKED meant off, and
"Allow Username Change" / "Allow users to self delete their account" / "Display
Authentication Method" as Yes/No radios. Half the rows meant the opposite of the
other half, and the word Allow or Disable was repeated on every one of them.
One group title says it once - "Login: Allow" - and every row under it is a
checkbox that is ticked when the thing is allowed:
Disable Forgot Password -> [_] Forgot password
Disable Self-Registration -> [_] Self-Registration
Allow Username Change (Yes/No) -> [_] Username Change
Allow users to self delete their account (Y/N) -> [_] Self delete user account
Display Authentication Method (Yes/No) -> [X] Display Authentication Method
`disableForgotPassword` and `disableRegistration` are stored as "disable" flags, so
their checkbox asks `unless`: only the DISPLAY is inverted, the stored fields and
their handlers are untouched. The three former radios write on click like the
checkboxes they now are - a checkbox that has to be confirmed by a Save button
further down the pane is a checkbox you think you have already set - so the Save at
the bottom keeps only what is still a field: the default authentication method and
the OIDC button text.
Translations: `forgot-password` already existed and is already translated
everywhere, so the row reuses it and `disable-forgot-password` is gone;
`disable-self-registration` becomes `self-registration`, whose name no longer
contradicts what the row means; `display-authentication-method` is reused as it is.
The two account settings keep their keys - `accounts-allowUserNameChange` and
`accounts-allowUserDelete` still describe the setting exactly - and only lose the
"Allow" their group title now carries, so every language keeps its translation
until Transifex offers the shortened source.
One bug fixed on the way: a dead `js-toggle-display-authentication-method` handler
that only toggled a CSS class sat LATER in the same event map than the real one. A
duplicate key in an object literal silently overrides the earlier one, so it would
have swallowed every click on the new checkbox.
Thanks to xet7 !
Two settings, neither of which was ever written:
* "Email domain name" (mailDomainName). The Save handler starts with
checkField('#mail-server-host'), and the SMTP block is commented out of this
pane's markup - checkField THROWS on an input that is not there, and the throw
was caught and swallowed, so the handler returned before its Settings.update.
Pressing Save did nothing at all.
* "Allow Email Change" (accounts-allowEmailChange). The radios rendered the
stored value and NO handler anywhere in the app wrote them back.
The Save button moves out of the Yes/No row - where it read as part of that one
radio pair - to its own line below both settings, and writes both: the domain into
Settings, the Yes/No into AccountSettings. Every field is written only when its
input is actually rendered, which is the guard the rest of these panes use, so the
SMTP fields being commented out can no longer abort the save.
And the label is renamed with its value, because "Email domain name" said nothing
about what the field decides and read as if it limited who may sign in. It does
not: a NON-ADMIN whose address ends with this domain may send board invitations,
and only while self-registration is disabled (isNonAdminAllowedToSendMail in
server/models/settings.js). The key `can-invite-if-same-mailDomainName` becomes
`email-domain-allowed-to-invite`, "Email domain allowed to invite people, when
self-registration is disabled".
Thanks to xet7 !
Every row in that group repeated the group title and the word "Hide": "Hide card
counter list on All Boards" under a title reading "All Boards". The title says
"All Boards: Hide" and each row says only what is hidden:
Boards visibility: Allow private boards only -> Public boards
Don't show the board activities on all boards -> Board activities
Hide card counter list on All Boards -> Card counter list
Hide board member list on All Boards -> Board member list
The three keys used only by this pane are renamed with their values -
`board-activities`, `card-counter-list`, `board-member-list` - because their names
described the old wording. A renamed key falls back to English until it is
retranslated, which is the honest outcome here: a translation of "Hide card
counter list on All Boards" is not a translation of "Card counter list", and
keeping the key would have shown the old sentence under the new title in every
language but English.
Two keys are NOT touched, and that is the point of the two new ones:
`all-boards` is the menu and page label everywhere else, so the group title is a
new `all-boards-hide`;
`tableVisibilityMode-allowPrivateOnly` is the message boardBody.jade shows on a
board you may not open - where "Public boards" alone would say nothing - so the
row label is a new `public-boards` and the setting's own key keeps its sentence.
(It is also the _id of the TableVisibilityModeSettings document, which no rename
may touch.)
Thanks to xet7 !
Each of the four sections - All Boards, URL, Product name, Logo - now ends with
its own Save, directly above the horizontal rule that closes it, and each handler
writes only that section's fields. One Save for the whole pane meant pressing it
in one group also wrote whatever was half-typed in another, and it was easy to
miss which button belonged to what.
Three buttons are folded into their section's Save and are gone with their
handlers: the pane-wide `js-tableVisibilityMode-save`, the single-setting
`js-hide-board-activities-save` sitting mid-section, and `js-support-save` inside
the Support block. The Support page's Enabled / Public checkboxes still save on
click, as before - they are toggles, not fields.
The guard that every one of these moves has needed is kept and is now in one
place: a field is written only when its input is actually RENDERED
(`$(sel).length`, `!== undefined` for a radio). Reading an absent input gives ''
or undefined, and writing that blanks a stored setting or silently turns it off.
Thanks to xet7 !
Every group but the first is now separated by a horizontal rule - URL, Product
name, Logo. All Boards opens the pane directly under its title, where a rule would
separate it from nothing.
Thanks to xet7 !
The group holds ONE field, so a group title above a label that says the same thing
printed it twice. The group title stays - at the group title size - and takes the
field's own translation (`custom-product-name`, "Custom Product Name"), which is
the string that already exists in every language; the field's separate label is
gone, and so is the English-only `settings-group-product-name` key added for it
yesterday, which nothing uses now.
Thanks to xet7 !
Top to bottom, under the pane title:
All Boards boards visibility (allow private only), don't show board
activities on All Boards, hide card counter list, hide board
member list, wait spinner
URL Support (link, enable, title/content), custom help link URL,
custom legal notice URL, custom URL schemes
---
Product name the custom product name
---
Logo hide logo, the login logo image/link/text, the top-left corner
logo image/link/height
The settings themselves are untouched, and so is every input id - the one Save
button at the bottom looks its fields up by id, not by position, so grouping them
changed nothing about what it writes. The three dedicated Save buttons (board
activities, Support, and that one) stay with what they save.
A group title uses .admin-pane-group-title: 1rem against the pane title's
1.25rem, so the page reads as one heading with groups under it rather than as
several pages stacked. Three new English strings for the titles that had no key -
URL, Product name, Logo; All Boards reuses the key it already has.
Thanks to xet7 !
Broken cards was the one entry in this menu with a different set of controls: no
search box, no total, no "page X / N", just a prev/next of its own - because it
ran on the global-search machinery (CardSearchPaged, a session document and the
nextPage/previousPage publications) instead of the shared table page. It is a
column spec in REPORT_TABLES now, like Files, Rules, Boards and Cards, driven by
the same loadReport(): a new admin-only `brokenCardsReport` publication takes a
search term plus limit/skip and publishes ONE page manually (a returned
sorted+limited cursor hangs on FerretDB's OpLog, as with the other reports), and
`getBrokenCardsReportCount` gives the total behind the counter.
What "broken" means - no board, swimlane or list, or a type that is not a card
type - is now one selector shared by the report and by the standalone
/broken-cards page, which still runs on the global search and keeps its own
publication unchanged.
The menu is two named groups. Summary, then a rule and a "Settings" title over the
two panes that came from Admin Panel / Features, then a rule and a "Reports" title
over the reports. A title is a new kind of menu item - `{ heading: true, labelKey }`
- with no id, no icon and no handler class, so there is nothing to click, nothing
for the page's click handler to read a data-id from, and it can never be the active
row (or a group name could end up as a pane title). Both use an i18n key the app
already has, so no language has to translate anything new.
Performance moves down to sit with the Speed, Tests and CPU usage streams it is
about, below Impersonation Report - it was three groups away from them, up with the
other two Features panes.
While there: the separator between groups is styled with the menu itself. The rule
for it lived in adminReports.css, twice, targeting a class the shared menu does not
render - so it had never applied to anything.
Thanks to xet7 !
Admin Panel / Attachments / Backup showed "Backup" twice: the pane heading comes
from the open left-menu entry now (docs/Design/Page/Left-Menu.md), and every
Attachments pane still printed its own name under it. Those h3s are gone - all ten
of them - and with them the same repeat on Roles, Shared templates and Broken
cards.
A heading that says something the menu label does not is not a repeat and stays:
Limits keeps "Attachment And API File Size Limits" and Locked users keeps "Brute
Force Protection Settings", neither of which is the label of the row that opened
it.
tests/leftMenu.test.cjs now reads every h1-h3 in the Admin Panel templates and
fails on one whose text is a menu label - by i18n key, or by the English string
for a literal heading like the Sandstorm one.
Thanks to xet7 !
The row at the top of a menu and the pane that opens are the same one now - the
rule Admin Panel / Settings follows for Version. Backup was moved to the top of
the Attachments menu while the page still opened on Move attachments, so the menu
highlighted the second row on arrival.
Landing on Backup asks once whether a backup is running (pollBackupStatus only
keeps polling while it is), so arriving during one shows its progress instead of a
pane that looks idle.
Thanks to xet7 !
Reported one after another, all in the Admin Panel, and they turned out to share
two causes: a stylesheet deciding a table's width from outside the design that
owns it, and a pane having to write for itself what every pane needs.
The tables
* Admin Panel / People / People rendered NOTHING - no table, no search box, no
pager. `buildFilters` and `buildActions` were used in peopleTablePageData but
never imported. That is not a build error: it is a ReferenceError thrown inside
a helper while rendering, which Blaze answers by rendering nothing at all.
Organizations, Teams and Domains use neither function, so they drew normally,
which is what made it look like a People-only problem.
* The right-hand side of a table was off screen - reported on Domains, and just
as true of Admin Panel / Version, where the value column was cut off at the
window edge. Two admin stylesheets forced `min-width: 1200px !important;
width: max-content !important` with nowrap cells on a bare `table` selector.
peopleBody.css had no page in the selector at all, so it reached every table in
WeKan, and `!important` beat the shared table page's own width:100% +
table-layout:fixed. The same rules also made a SHORT table shrink to its
content, which is why Domains sat at a third of the panel on a narrow window.
No admin table is forced wide any more: it fits its panel and its cells wrap,
and the phone-width exception that used to undo the floor is simply the rule at
every width. The shared table page's width and wrapping are `!important` now -
a guarantee a stylesheet in another folder can silently override is not a
guarantee.
* An empty table page rendered no table at all, and the "New" link of
Organizations, Teams, People and Translation is a column HEADER - so an empty
pane had no way to create the first row. The table always renders now; the
"no items" message moved below it.
* The controls row: every control shares one height and no margin. forms.css is
`button { display: block; margin-bottom: 14px }`, written for stacked form
buttons, so a button that kept that margin was centred higher than one that did
not - "Unlock all users" sat lower and shorter than "Teams" beside it, since it
also carried a 20px margin and a 28px height from the old hand-written header.
Action buttons are themed with the pager, in the one stylesheet that owns those
colours, every state spelled out, or a bare <button> falls through to the
forms.css fallback, which is literally black.
Admin Panel / Settings / Translation now renders through the shared table page
(docs/Design/Page/Table.md) instead of a hand-written table: four columns, an
interactive row, the "New" link as a column header. It pages ONE page of 25
server-side with limit/skip and a count method, where it used to grow a window by
infinite scroll; the publication publishes the field it is sorted by, so the
client's sort matches the server's page.
The pane title
Every Admin Panel pane opens with the same heading, and the heading is the ACTIVE
LEFT MENU ENTRY's own label - `paneTitle()` in models/lib/leftMenu.js, one class
`.admin-pane-title`, which the shared table page's own title carries too. Before
this only the paginated table pages had a title at all: Domains said "Domains"
while Login, Announcement, Accessibility, PWA and Version opened with no heading.
Deriving it from the menu is what keeps them identical - a pane cannot end up with
a title of a different size or none at all - and it is why a table page inside the
Admin Panel now passes no titleKey: the section already rendered the heading.
The menus
* Version is the FIRST pane of Admin Panel / Settings and the one that opens with
the page, so what an admin sees first is the version, database and system
information they usually came for. Its page, its one-entry menu and its tab are
gone - a page whose menu had a single entry was a page in name only - and
/information redirects to Settings, the same move Translation made.
* Admin Panel / People: Domains moves up beside E-mail, the settings it is about.
* Admin Panel / Attachments: Backup moves to the top.
Tests: tests/tablePage.test.cjs gains the Translation conversion, the empty-table
header, the one-height controls row, the themed actions and a guard that no admin
stylesheet may force a table's width; tests/leftMenu.test.cjs gains the pane title
(helper, template, every page renders it, one shared size) and Version as the
first Settings pane; tests/translationPane.test.cjs is rewritten for the pane that
is left once the shared design owns the table.
Thanks to xet7 !
Admin Panel / Problems is the longest menu - 15 entries since Performance, Security
and Notifications joined it - and its last four sat on the page's grey with no panel
behind them.
The panel is a flex item stretched to the row's height, so its background, border and
rounded corners end at the bottom of the page. With the default `overflow: visible`
the entries simply kept rendering past that edge. Nothing was hidden and nothing was
unclickable; the menu just stopped looking like a menu halfway down.
It scrolls now. `min-height: 0` goes with it: a flex item does not shrink below its
content without it, so the box would stay as tall as the list and the overflow would
never engage - the rule would look right and change nothing.
Whatever is visible is now always on the panel, at any window height and for any menu
length, rather than depending on the menu being short enough.
Tests: 1380 passing.
Thanks to xet7 !
`./build.sh` stopped with
Jade compilation error in peopleBody.jade: Can't use the built-in 'if' here
A `//-` comment placed BETWEEN `if loading.get` and `else if registrationSetting.get`
splits the chain, and the orphaned `else if` is not a valid statement. The comment
moves above the chain, where it was meant to be, and says why it has to stay there.
The real failure is that tests/jadeCompiles.test.cjs was green while the build was
red. It called JadeCompiler.parse() only, and this error is not a parse error - the
loader parses and THEN runs SpacebarsCompiler.codeGen on the body and on every
template, and that is the step that rejects the orphaned else. A suite written to
catch "a broken template breaks the build" missed a broken template that broke the
build.
It now does both steps, exactly as npm-packages/meteor-jade-loader does, and a
negative test pins the gap itself: the broken chain must throw through compile(), and
the same input is fed through parse() alone in the same test to show that parsing does
NOT see it. If that parse ever starts throwing, or the compile stops, the check has
been weakened back to what missed this.
Verified by running the actual loader function - the one rspack calls - over
peopleBody.jade, adminReports.jade and settingBody.jade, which now all generate code.
Tests: 1379 passing.
Thanks to xet7 !
Its last three panes - Performance, Security and Notifications - moved to Admin Panel /
Problems in 4df87fd6b, leaving a tab that opened an empty page.
Removed: the /admin-features route, the tab in the Admin Panel bar, its isFeaturesActive
helper, both imports, and adminFeatures.jade / adminFeatures.js.
NOT removed, and this is the whole risk in the change: the three pane templates and
their helpers and handlers lived in those two files. Deleting them would have left
Problems rendering three templates that no longer exist - which is not a build error.
The app compiles and loads, and then throws `No such template: featuresPerformance`
when the pane is opened, losing whatever else that view was drawing. They move to
adminReports.jade / adminReports.js instead, with the page that renders them, together
with the toggleSettingField() helper the handlers call.
tests/templateIncludesResolve.test.cjs is new and general: every `+templateName` in
every .jade must name a template that exists. It is the mirror of
templateHandlersExist.test.cjs, which catches a HANDLER on a template that does not
exist; between them a template can neither be referenced without being defined nor
extended without existing. It also asserts the removed page's route, tab, helper and
imports are gone - a tab that survives its page leads to a route rendering a template
that is not there.
Five includes are package-provided rather than ours (fullcalendar, atForm, mentions,
markdown) plus one pre-existing (subtaskDeleteDialog); they are listed explicitly so
the check stays honest rather than being loosened.
Tests: 1378 passing.
Thanks to xet7 !
The Problems menu now reads:
Summary
Performance | Security | Notifications (moved from Admin Panel / Features)
Speed, Tests, CPU usage
--
Security Report
Impersonation Report
Broken Cards, Files, Rules, Boards, Cards, Recovery
"Security" is renamed "Security Report" and moved above Broken Cards, with
Impersonation Report directly between the two. The rename is what makes the rest safe:
the pane arriving from Features is ALSO called Security, and the two now sit in one
menu. It is the English SOURCE string that changed (securityReportTitle), so every
other language keeps its existing translation until that string is retranslated - no
human translation is overwritten, and the key is unchanged so nothing else moved.
One correction worth stating: the request named Admin Panel / SETTINGS as the home of
Performance, Security and Notifications. They are Admin Panel / FEATURES panes -
Settings has no entry by any of those names - so they were taken from there, which is
the only place they exist.
Their handlers and helpers came with them, which is the half that fails silently. All
twelve helpers and twelve toggles were registered on Template.adminFeatures; Blaze
resolves a helper, and delivers an event, against the template the element is IN,
never an enclosing one. Left there, each pane would have rendered on Problems with
every checkbox reading as unchecked and no click doing anything. Each pane is its own
template now, and the shared helper/handler pair is registered on all three - a handler
whose element is not in a given pane simply never fires there, so splitting them per
pane would buy nothing.
That leaves Admin Panel / Features with no panes at all. Its page, menu and route stay,
so nothing linking there breaks and a future feature has a home, but the tab is empty
until it gets one. Removing the tab is a separate decision and is not made here.
Tests: 1374 passing.
Thanks to xet7 !
Both panes are about the people who can sign in and how they are reached, which is
what the People page is for. They are its first two entries now, and Login is the pane
that opens with the page.
The move is only half markup. EVERY handler those two panes need was registered on
Template.setting - the toggles for forgot-password, self-registration, same-org board
members and Display Authentication Method, the invite-people button and its board
chooser, the account-access Save, and on the E-mail side the TLS toggle, the SMTP Save
and Send test e-mail. Blaze delivers an event to the handlers of the template the
element is IN, so left on Template.setting each pane would have rendered on People and
then quietly done nothing: no toggle sticking, no Save saving, nothing in the console.
All ten moved onto Template.general and Template.email, the templates that draw them,
where they work wherever the pane is rendered. Template.general also gains
accountAccessHelpers, which Template.email already had - a helper the host template
lacks renders as unchecked, which silently shows the wrong value.
The pane TEMPLATES stay in settingBody.jade beside the other admin panes, since Blaze
templates are global and their handlers now sit beside the other settings handlers.
Both files say so where a reader would look for them.
Settings loses the two entries, their id-map rows, their reactive vars and their
isGeneralSetting / isEmailSetting helpers. generalSetting was the var that started
true, so Visibility - the first entry left - is promoted to open with the page;
without that the Settings page would open on no pane at all. The Sandstorm exception
that drops the E-mail entry moves to People with it, so peopleMenu() is a function
now rather than a bare array, because it has to read Meteor.settings at call time.
Ids and i18n keys are unchanged, so every existing translation still applies.
tests/loginEmailPanesMoved.test.cjs pins the whole move, including the half that fails
silently: each handler must be on the pane template and NOT on Template.setting, the
panes that stayed must keep theirs, exactly one pane may start open, and both pane
templates must exist for their handlers - registering on a missing template throws at
module load and takes out every module after it, which is how the password field
vanished from /sign-in earlier in this series.
Four existing suites asserted these panes were part of Settings and now assert them as
part of People.
Tests: 1368 passing.
Thanks to xet7 !
CRITICAL SECURITY ISSUE (CWE-22 Improper Limitation of a Pathname to a Restricted
Directory, "zip-slip").
A zip entry carries its own path, chosen by whoever built the archive, and path.join()
RESOLVES `..` segments instead of rejecting them. The restore checked only that an
entry's FIRST path segment was `attachments` or `avatars`, then joined the rest onto
the matching directory:
const rel = entry.path.split('/').slice(1);
const kind = rel[0];
if (kind !== 'attachments' && kind !== 'avatars') continue;
const destPath = path.join(attachmentsDir(), ...rel.slice(1));
So an entry named
2026-07-25_12-00-00/attachments/../../../../etc/cron.d/wekan
satisfied that check - its first segment really is `attachments` - and joined its way
clean out of the files directory. With attachmentsDir() = /data/files/attachments it
resolves to /etc/cron.d/wekan, and the entry's contents were streamed there. A crafted
backup.zip could drop or overwrite a file anywhere the WeKan process could write.
restoreBackup is behind requireAdmin(), which is less of a barrier than it sounds:
that is exactly how a hostile archive arrives - offered as a backup to restore, at the
one moment nobody inspects the file they were handed, and nothing in an archive is
visible before it is unpacked.
Fixed in models/lib/backupPaths.js, next to the other pure backup helpers so it is
unit-testable without Meteor: safeEntryPath() resolves the candidate to an absolute
path and requires it to sit under the target directory. It compares against the base
plus a separator, because a bare startsWith(base) also accepts a sibling directory
whose name merely begins with the same letters (/data/files/attachments-evil). An
absolute segment is caught by the same check, since path.resolve discards everything
before it.
The data half of an archive names the Mongo collection to restore into, and that name
came from the entry too, so safeCollectionName() constrains it to a plain
[A-Za-z0-9_-]+ name - which also keeps a restore out of the database's internal
system.* collections, excluded from backups in the first place.
A refused entry is skipped and logged rather than thrown on, so one hostile entry in
an otherwise good archive cannot abort a genuine restore.
This is WeKan's own code, not a dependency: it is the same class as the unzipper
advisory GHSA-884w-698f-927f, but WeKan runs unzipper 0.12.x, which that advisory does
not affect. Found while reviewing the open dependency pull requests.
tests/zipbleed.test.cjs asserts the exact traversal above is refused, that a plain
entry still restores where it belongs, that absolute segments and prefix-matching
siblings are refused, and that the restore really calls both guards. One assertion
reproduces what the OLD code did with the attack path - path.join returning
/etc/cron.d/wekan - so the suite states the danger, not just the remedy.
Tests: 1359 passing.
Thanks to xet7 !
Two reports, one of them the same bug in a third place.
Domains - and with it every other shared table page - needed scrolling to the right
to see its last columns. settingBody.css gives EVERY table in the admin body a 1200px
floor, `width: max-content` and nowrap cells, written years ago to force a horizontal
scrollbar. Applied to `.table-page-table` that overrode exactly what makes the shared
page fit: width:100%, table-layout:fixed and wrapping cells (docs/Design/Page/Table.md).
The three rules now exclude `.table-page-table`; the genuinely wide admin tables -
GridFS statistics, Version, Translation - keep them. The panel's `overflow-x: scroll`
becomes `auto` in the same breath, so a page whose content fits no longer shows a
scrollbar with nothing to scroll to.
Admin Panel / Settings / Translation showed no rows and no way to add one.
`translationList` is a helper of Template.translationSettings, but
`each translation in translationList` is written inside translationGeneral - a
different template. Blaze resolves a name against the current template's helpers, the
global helpers and the data context, never an enclosing template, so the list came out
undefined and the tbody was empty. The parent hands the list down now. This is the
third instance of that one mistake today: Organizations, Teams and People had it too.
Its Search button was BLACK. forms.css styles every bare <button> from
`var(--theme-accent, #000)`, and with no per-user theme chosen that fallback is
literally black. It takes the same colours as the other admin buttons now - the accent
when one is set, the WeKan button blue when it is not. Every state is spelled out
(:hover, :focus, :active, :active:hover) because forms.css sets each of those from the
same variable with its own black-ish fallback; overriding only the resting state
leaves a button that turns black the moment you touch it.
tests/uiDensity.test.cjs asserted against the old unscoped td/th selectors and now
asserts the scoped ones, with a note about which tables they are for.
Tests: 1352 passing.
Thanks to xet7 !
Replaces the darker-and-bold label from b775ee1e1 with the treatment the Admin Panel
bar already uses for its selected tab (settingHeader.css, `.setting-header-btn.active`):
the entry is FILLED with the theme colour and its label and icon go white. One
selected-thing look in both places.
The colour is the per-user theme accent, which Member Settings -> Change color sets on
:root, so a user with a green theme gets a green entry. The fallback is the WeKan
header blue, so with no chosen colour the menu matches the bar exactly.
`li.active:hover` is in the selector list on purpose: `li:hover` sets a white
background at the SAME specificity and comes later in the file, so without it the fill
washed out the moment the pointer crossed the selected entry. The now-dead
`background: #fff` on the plain `.active` rule is removed; its shadow stays.
Tests: 1347 passing.
Thanks to xet7 !
Organizations, Teams and People drew their search box and their pager but NO TABLE.
Their wrappers said `+tablePage(orgTablePageData)` while that helper was registered on
Template.people - the PARENT template. Blaze resolves a name against the current
template's helpers, the global helpers and the data context; it never searches an
enclosing template. So the context came out undefined, and a table page with no
rowCount draws its chrome and stops. Nothing threw and every test passed.
Domains is the control that proves it: its helper sits on Template.domainGeneral, the
template that uses it, and Domains kept working the whole time.
The parent builds the context now - where the helper actually lives - and hands it
down, so each wrapper renders `+tablePage(this)`. The named arguments the wrappers
used to take (orgList, orgCurrentPage, hasOrgPrevPage, ...) went unused once these
panes moved to the shared page, so they go too.
A new test walks every `+tablePage(name)` in that file, works out which template it is
written in, and requires `name` to be a helper OF THAT TEMPLATE unless it is `this`.
Verified it flags `orgGeneral -> orgTablePageData` when the bug is put back.
Also: the selected left-menu entry is darker and bold, so the menu says at a glance
which page is showing on the right. Its colour fell back to `inherit`, which made it
exactly the same grey as every unselected entry - the white background and soft shadow
alone were easy to miss. A per-user theme accent still wins; only the fallback changed,
from `inherit` to a grey darker than the panel's. The icon takes the same colour as its
label.
Tests: 1347 passing.
Thanks to xet7 !
The Visibility pane now reads, top to bottom:
Custom Product Name
Hide Logo
Boards visibility: Allow private boards only
Don't show the board activities on all boards
... the rest, unchanged
Custom Product Name and Hide Logo were far down the pane among the logo URLs; they
are the two settings that name and brand the instance, so they belong above the
visibility choice rather than below a dozen link fields.
"Don't show the board activities on all boards" had a left-menu pane of its own for
one radio pair. It is a visibility setting, so it moves into this pane, directly under
the visibility choice, and the pane, its menu entry, its reactive var, its helper and
its branch of the pane switch all go with it. Its own Save button moves with it: the
click handler is registered on the parent template, so it keeps working by delegation
exactly as before, and folding the field into the pane's main Save would have meant
rewriting that write for no gain.
Its save handler is untouched, so the guard that matters still holds: a radio it
cannot find is skipped rather than written as false. That is the trap this whole
series of moves keeps setting - a save left reading an input that moved silently
turns the setting off.
Tests: 1346 passing.
Thanks to xet7 !
Every Admin Panel page except Problems drew a title bar under the top bar, repeating
the name of the pane you were already looking at: "Registration" above Settings, "Info"
above Version, and so on. The top bar already says which section you are in and the
left menu highlights the open pane, so the third line only cost vertical space.
Problems has never had one; the rest match it now.
Settings, Version, Features and Attachments carried nothing but a title, so their bars
are simply gone.
People's bar was not only a title: the Organizations and Teams panes searched from a
box and button inside it, and it showed their row counts. The searches move into the
shared table page's controls row - which is where People's own pane already searched
from - and the counts were already shown there as the table's total, so they needed no
new home. One keydown handler now dispatches on the open pane, the way the pager and
the filters already do, and each pane keeps its own search term so switching panes does
not carry a search across.
What the bars left behind goes with them: the `.ext-box` rules in peopleBody.css and
translationBody.css, `.content-title` in settingBody.css, and the three count helpers
that fed the bar - all dead once the markup went, and all verified unreferenced first.
CSS was removed rule-by-rule with a brace-balance check before and after, because
line-filtering this same file orphaned five rule bodies once already.
Three existing tests asserted things that were true only while the bars existed - the
themed search button, the search handler's scoping, the PWA pane header - and now
assert the same properties in their new homes.
Tests: 1346 passing.
Thanks to xet7 !
Settings, People, Features, Attachments, Version and Problems all rendered an empty
panel where their left menu belongs.
The seam between the two halves of the shared menu was wrong. leftMenu.jade iterates
`each items`, and every page handed it the bare ARRAY that buildMenuItems returns - so
Spacebars looked `items` up ON the array, found nothing, and rendered nothing. The
template's own comment said the data context is `{ items }`; the six call sites did
not provide it.
Nothing failed anywhere: the template was correct, the helper was correct, every unit
test passed, and the menu was simply not there. Six pages lost their navigation to one
mismatched shape.
A new leftMenuData() states that shape once, in models/lib/leftMenu.js, and all six
pages build their context through it. buildMenuItems keeps returning an array, which
is what activeCount and the tests want.
The guard that was missing is the one that checks the SEAM rather than either half:
it reads which variable leftMenu.jade iterates, calls leftMenuData, and asserts the
returned context actually has an array under that name - so renaming the loop variable
or handing back an array fails the suite. A second test asserts no page calls
buildMenuItems directly in its menuItems helper, since that is exactly the mistake
that empties one page's menu while the others keep working.
Verified both fail when the bug is put back, then pass again when it is removed.
Tests: 1346 passing.
Thanks to xet7 !
The fixed-size light grey band between the blue resize bar and the next swimlane's
dark header - the one that travelled with the bar as the swimlane was resized - is
gone, along with its twin between a swimlane's header bar and its first list.
They were plain bottom margins on the swimlane header (1rem) and on each list (2rem).
On the LAST list that margin is exactly the band between the content and the resize
bar; being a fixed size it moved with the bar rather than growing, which is what
"moves along" described. Lists are separated by the 2px border under each of them, so
nothing is lost by removing it.
The reason the previous attempt did not take: boardHeader.css restates the same
selectors in SEVERAL later blocks - the mobile overrides, a max-width media query, and
a "force mobile mode to override any media query styles" block. Later rules of equal
specificity win, so zeroing the margin in the first block only looked fixed while
eight duplicates put it straight back. All of them are zeroed now.
That is the more useful lesson, so the test checks EVERY block in the file rather than
the first one it finds: no rule under .mobile-mode may leave a non-zero bottom margin
on a swimlane, a swimlane header or a list, written as either `margin-bottom` or the
four-value `margin` shorthand. Verified it fails when one duplicate is put back, so it
is not passing by construction.
Tests: 1344 passing.
Thanks to xet7 !
Follow-up to 4d67952ec, correcting it on two counts.
The grey band between the blue resize bar and the next swimlane's header was the 2rem
bottom margin on `.mobile-mode .swimlane`. The bar is pinned to the bottom edge of the
lists container, so a margin AFTER that container is a fixed band of grey sitting under
the bar - and it travels with the bar as the swimlane is resized, which is exactly how
it was described. The margin is gone: on a phone every swimlane already begins with its
own darker header bar, which separates them perfectly well. That also removes the same
band from between a swimlane's own header and its lists, since the selector matches the
header wrapper too - so the separate override added for that in 4d67952ec is no longer
needed.
The header wrapper is now only as tall as the header bar inside it. It is a `.swimlane`
as well, so it picks up that element's sizing, and anything left over renders as the
lighter grey of `.swimlane` around the darker bar.
And 4d67952ec was wrong to force `height: auto !important` on the lists container. The
height being dragged IS that inline style, so overriding it made the resize bar do
nothing at all. Only the floor is removed - `min-height: 150px` held a short swimlane
open below the height chosen for it, and THAT leftover was the grey above the bar. The
chosen height is honoured, so what is above the bar is whatever the swimlane was
resized to.
A test now asserts the dragged height is NOT overridden, so this cannot be
"fixed" back into a bar that does nothing.
Tests: 1343 passing.
Thanks to xet7 !
The blue resize bar is pinned to the bottom edge of the swimlane's lists container, so
any height that container has BEYOND its content shows as a band of empty grey between
the last list and the bar. On a phone there was a lot of it.
Two things gave it that extra height, and both are desktop assumptions:
* the container carries an INLINE `height` from the stored swimlane height - a height
the user chose for the DESKTOP layout, where lists sit side by side. Stacked full
width in mobile mode the same lists need a completely different height, so the
difference showed as dead space (and made the container scroll vertically on its
own, which is the second scrollbar in the screenshot);
* `min-height: 150px` on .swimlane.js-lists.js-swimlane held a short swimlane open
even when its content was smaller.
In mobile mode the container takes its content height instead, so the bar lands
directly under the last list - which is also directly above the next swimlane. Both
need !important: an inline style loses to nothing less.
Also removes the gap between a swimlane's header and its OWN lists. The 2rem bottom
margin is meant to separate one swimlane from the next, but `.mobile-mode .swimlane`
matches the header wrapper too, so the same 32px band sat between a header and the
lists belonging to it.
Tests: 1342 passing.
Thanks to xet7 !
Regression from moving Add List into the mobile list header in 61979c0f6. In mobile
mode the whole list row is an `a.mini-list.js-select-list` and the + sits INSIDE it,
so one click did both things: it opened the composer AND selected the list, so asking
to add a list took you into one instead.
The handler already called preventDefault, which is a different thing - it stops the
anchor's own navigation, not the click travelling up to the ancestor's handler. It
needs stopPropagation.
Harmless on desktop, where the button is not nested inside a select-list anchor.
Tests: 1340 passing.
Thanks to xet7 !
The lists area was a little too wide - a horizontal scrollbar with a small amount to
scroll right and nothing there to see. Two causes.
`100vw` again. It was fixed in boardHeader.css in 72315d8f9, but boardBody.css (18
values) and list.css (32) had the same thing, including `.mini-list.mobile-view` -
the very rows a phone shows. 100vw is the viewport width INCLUDING the vertical
scrollbar, so each of those was a scrollbar wider than the box it sat in. They had
been dormant: the `.mobile-view` class comes from isMiniScreen, which only started
being true on a desktop window once the explicit mobile-mode toggle began driving it.
An absolutely-positioned 100vw hairline in the settings body went the same way - it
stuck out past its parent and made that page scroll sideways too.
100vw is KEPT where it is right: a position:fixed overlay (the mobile card details,
a popover, the sidebar, the notifications drawer) is sized to the viewport by
definition and is not in the flow of a scrolling container. A test asserts that the
two it checks really are position:fixed, so the exception cannot be borrowed for an
in-flow element.
box-sizing. `* { box-sizing: unset }` (layouts.css) makes content-box the default, so
a rule that sets `width: 100%` AND `padding: 1rem` is 32px wider than its parent. The
swimlane header, the list header, the list body and the minicard all do exactly that,
at four nesting levels. They now measure their padding inside.
Then the vertical alignment, in four places:
* The swimlane title was a block at the TOP of a band whose height comes from the
padding and the icons beside it. It is a flex box centred on its line now, and the
wrap centres its children so the title and the icon row share one centre line.
* The list title was pinned to the BOTTOM of grid row 1 with the card count pinned
to the TOP of row 2, so the pair hugged the middle - but with no card count row 2
is empty and the title sat in the upper half. Both centre in their own row.
* The quick-access bar declares `height: 28px`, which with box-sizing unset is the
CONTENT box. Its children are ~40-44px on a phone for touch, so they overflowed a
short box, were clipped by its `overflow: hidden`, and read as sitting high. The
bar takes its content height with a 48px floor and symmetric block padding.
* The board bar centred its items inside a box padded 7px above and 0 below, which
put everything half that distance high; its padding is symmetric now, and the
title's own line box is tightened so the text centres rather than floating at the
top of a tall line.
Tests: 1339 passing.
Thanks to xet7 !
On a phone the "+ Add List" composer stood as a row above the lists, spending a whole
row on one button. The + now sits in each list header, BETWEEN the caret and the drag
handle, so the caret moves left and the + takes the middle of that group.
This is what desktop already did. #6465 moved Add List into the list header there and
left the mini-screen path alone, so the two had drifted apart. The mobile button now
uses the SAME class (js-add-list-here), therefore the same click handler and the same
behaviour - open the inline composer after this list - and the same Font Awesome icon,
fa-plus-square-o. One button in two layouts rather than two lookalikes that can drift
again.
The mobile list-header grid grows from four columns to five: title, caret, +, handle.
RTL mirrors on its own. Nothing here is placed with a physical left/right: the header
is a CSS grid, and a grid lays out along the INLINE axis, so under dir="rtl" column 1
is on the right and the whole row reverses - handle, +, caret, title. A test asserts
no physical side creeps into any of the three placements, since one `right:` would
strand a control on the wrong edge.
An empty swimlane and an empty board keep a + of their own, as on desktop: there is no
list header to host the button when there are no lists, and without it the first list
could never be created.
The addListForm template is removed. It rendered that standing row, mobile mode was
its last caller, and it is dead once the button moves. Its three handler blocks go
with it - a Template.X.events() left on a removed template throws at MODULE LOAD and
takes out every module after it in the client bundle, which is how the password field
disappeared from /sign-in in 696c49038. tests/templateHandlersExist.test.cjs covers
that, and passes.
Two existing suites referred to addListForm in comments describing the old shape;
both are updated to describe the current one.
Tests: 1332 passing.
Thanks to xet7 !
Asked whether the same clamp()/viewport-unit bug exists anywhere beyond the
stylesheets already swept. It does not - but the guard only ever looked at
`client/**/*.css`, so "it does not" was not something the suite could actually say.
Three places a viewport unit renders exactly like a stylesheet and the scan never saw:
* an inline `style=` in a .jade template (client/ and packages/)
* CSS built as a JS string - client/lib/exportHTML.js builds a card modal that way,
and sandstorm-src/migration-bridge.js builds a whole page
* stylesheets outside client/: our own packages/ and public/css
All three are now scanned, and all three are clean. What they do contain is the
allowed shapes, which is useful: the exported modal's `max-height: 80vh` keeps it
inside the window, and the migration bridge's `min-height: 100vh` is a full-viewport
box. Vendored stylesheets (fullcalendar, the jade-loader fixtures, FerretDB, .build
output, the generated Redoc page at public/api/wekan.html) are not ours and are
excluded.
A scan that silently reads nothing passes forever, so one more test proves these are
not vacuously green: it asserts the JS scan really finds the exported modal's cap in
the tree today, that the cap is allowed, and that the declaration splitter pulls
`padding:3vh 3vw` out of a run-together style string the way it would appear in a
cssText or a style attribute - and that the splitter's output is rejected.
Tests: 1325 passing.
Thanks to xet7 !
Reported on a board in mobile mode in desktop Firefox: widening the window made the
swimlanes, lists and cards taller; narrowing it shrank them again. The same complaint
as /sign-in and /sign-up, and the same cause - a size measured against the WINDOW
instead of being a size.
The earlier sweep converted 355 bare `vh`/`vw` values but explicitly ALLOWED
`min()`, `max()` and `clamp()`, on the grounds that they are caps. `clamp()` is not.
It is only a cap at its two ends; between them it tracks the viewport exactly like a
bare `vw`. So `font-size: clamp(18px, 2.5vw, 32px)` on a swimlane header, a list
header and a minicard is a font that grows with the window - and since those rows are
sized by their text, the rows grow with it. There were 75 of these across 17
stylesheets, 36 of them in the mobile-mode board rules.
All 75 are converted to the size they already rendered at on a phone - the lower bound
of each clamp. That is the value these rules were designed around (below ~800px the
clamp was pinned to it anyway), it is in line with the rest of the UI's fixed sizes,
and picking the upper bound instead would have made every phone bigger than it is
today.
Also converted, same behaviour by other spellings:
* `.board-sidebar { width: clamp(320px, 30vw, 560px) }` -> a fixed 420px. Its own
comment recorded 420px as the intended width; the clamp was added to stop a bare
30vw doubling on wide screens, but it still resized in between.
* `min-height: 3vh` on the mobile minicard -> 24px.
* `min-height: 60vh` on a collapsed list -> 540px, which is exactly what the
`height: 540px` on the very next line already says.
* `min-height: 60vh` (settings body) -> 540px; `min-height: 14vh` (search popover)
-> 126px.
* `max-width: 13vw` on a minicard custom-field chip -> 160px.
tests/noViewportSpacing.test.cjs no longer allows clamp() or a viewport `min-*`, and
says why. What stays allowed is a full-viewport box (100vh/100vw), a `max-height` /
`max-width` cap, and `min(400px, 52vw)` - a shrink-only cap, flat at the px above the
crossover width and giving way only below it so a box fits a narrow screen. It never
grows with the window, so it is not this bug; `max(...)`, which does grow without
bound, is not allowed. Both argument orders are accepted.
tests/sidebarWidth.test.cjs required `clamp()` for the sidebar - that was the fix for
the doubling, and it is now the thing being removed. It asks for a fixed px width and
no viewport unit at all, which is a stronger form of what it was guarding.
Tests: 1321 passing.
Thanks to xet7 !
Reported with two screenshots of the same app: on an iPhone 12 mini the second header
bar held a handful of icons and no board title, while a desktop Firefox window in
mobile mode showed the title and the full set of buttons. Same mode, two bars.
Mobile layout is driven from three switches that did not agree: `body.mobile-mode`
(the toggle), `Utils.isMiniScreen()` (which template branch renders) and
`@media (max-width: 800px)` (the viewport - true on a phone, false on a wide desktop
window even with mobile mode on). The first two were made to agree in a5246fbf5; the
rules that assumed the third are fixed here.
`.mobile-mode .board-header-btns.left { display: none }` is removed. The left group
holds edit title / visibility / watch / star / sort, and boardHeader.jade renders them
in EXACTLY ONE of the two groups - left `unless isMiniScreen`, right `if isMiniScreen`.
So in mobile mode the left group is already empty and hiding it changes nothing,
EXCEPT when the switches disagree, and then it deletes those five buttons from the bar
with no replacement. Gone, so that if the switches ever drift again the buttons survive
instead of vanishing.
The phone block gave the bar a fixed `height: 48px` for #6419's touch targets. A fixed
height CLIPS the second row the bar wraps to when title + buttons do not fit on one -
part of the bar was simply not there. Now `min-height`, so the targets keep their size
and the bar can grow; it still sits on one row whenever the content fits, which is the
normal case.
The list title is visible in mobile mode again, on both. listHeader.jade has two
shapes: on a mini screen the `h2.list-header-name` is a direct child of `.list-header`,
otherwise it is wrapped in a div (the one that rotates when a list is collapsed).
Mobile mode lays the header out as a grid and places the title by grid row/column,
which only applies to a direct grid ITEM - inside the wrapper the placement was ignored
and the title landed in the 30px first column, squeezed to nothing. `display: contents`
drops the wrapper from the layout so the title is a grid item in both shapes. Not for
`.list-rotated`, which needs a real box to rotate, nor for the screen-reader move
buttons.
The board reflows sideways again instead of overflowing by a sliver. The mobile board
rules sized the canvas, swimlanes, lists and list headers with `100vw` - the viewport
width INCLUDING the vertical scrollbar. The canvas scrolls vertically, so every one of
those was about a scrollbar's width wider than the box it sat in, at each nesting
level, and `min-width` pinned to the same value meant it could not shrink. All 18 are
now `100%`, which resolves against the parent's content box and already excludes the
scrollbar.
Tests: 1321 passing.
Thanks to xet7 !
On a coarse (touch) pointer the handle was a full-height strip down the LEADING
edge. That was added for #6521 for a good reason - on a touch device the handle is
the ONLY way to drag a card, since the card body deliberately pans the board
instead, so the 20-28px corner icon was too small a target to hit. It reached the
size goal but put the handle on the opposite side of the card from every other card
control, and from where a mouse user's handle already sits.
Both pointer kinds now put it in the same place: the details menu at the top of the
trailing edge, the drag handle directly BELOW it, as one column. The touch version is
just bigger. A mouse keeps the compact corner handle - `pointer: coarse` does not
match a mouse - and that one was already below the menu button, so the two placements
now agree instead of being mirror images of each other.
The touch target is not given up: the handle is 44px wide and runs from under the menu
button to the bottom of the card, so a tall card gives a tall target, with a 36px floor
for a card holding nothing but a title. The card reserves the column as trailing
padding so its text does not run underneath, and is at least 68px tall - menu (32) plus
handle minimum (36) - so both fit.
The menu button is pinned rather than floated inside that block: the card's new
trailing padding would push a float:inline-end button inward, and it would no longer
line up over the handle. Both are the same width, so they read as one column.
Everything stays in logical properties, so the column mirrors to the left edge on an
RTL board rather than being stranded.
The handle renders on `canMoveCard && showDragHandles()`, the same pair of conditions
that adds the `minicard-with-handle` class - so the reserved space and the handle
always appear together, never one without the other.
Tests: 1316 passing.
Thanks to xet7 !
Four things reported while using mobile mode, three of them in the second header
bar.
Drag-to-scroll now works on BOTH top header bars, not only below them. Everywhere
else a drag scrolls - `.board-canvas.dragscroll` on a board, `<body>` / `#content`
on the whole-page layouts - but the two header bars were dead, and on a phone they
are a large share of what is on screen. They cannot simply be tagged `.dragscroll`:
that class scrolls the element carrying it, and neither bar is a scroll container -
`#header` sits outside `#content` and outside the board canvas. So a new module,
client/lib/headerDragscroll.js, forwards the drag to whatever actually scrolls: a
scroller inside the header first (the starred-boards list is overflow-x:auto), then
the board canvas, then the page scroller. Both bars are `.nodragscroll` so the
page-level dragscroll does not scroll a second time from the same gesture. Mouse and
touch are both handled - a phone sends no mouse events, and the dragscroll library is
mouse-only and element-bound. A tap is still a tap: scrolling starts only past a 4px
threshold, and only then is the click that ends the gesture swallowed, in the capture
phase, so dragging across the bar does not press whatever you let go over.
The second header bar on a phone now reads title, buttons, hamburger. The board title
is shown again - it was hidden by a `display: none !important` that predates this
work, which left the bar with nothing but icons, so you could not tell which board you
were on. A board name is how you know where you are, so it wraps rather than
truncating. The buttons start at the right of the title and drop to a second row as a
block when the space between the title and the menu button runs out; they are one flex
item, so they never split across the two rows.
The sidebar hamburger, with its divider to its left, is pinned in the TOP RIGHT
corner. It was lifted out of the `.right` group into its own flex item placed after
the title, because inside that group it could only ever wrap down together with the
other buttons - a flex line breaks in order. On a phone it is taken out of the flow
(position:absolute) and the bar reserves its width as end padding, so a long title or
a full row of buttons never runs underneath it; that reservation is board-only, since
the same bar on All Boards has no hamburger. On a wide screen `order: 1` puts it back
at the end of the bar, visually identical to before.
Lists and cards are full width in mobile mode on a DESKTOP browser too, not only on a
phone. Two causes, both from mobile mode being decided in two places that disagreed:
* Utils.isMiniScreen(), which drives the `mobile-view` class on each list, swimlane
and minicard, looked only at screen width and user agent. The explicit toggle was
honoured on iPhone only - and even there through a test that could never be false,
since getMobileMode() falls back to viewport detection and so always returns a
boolean. An explicit choice now wins on every device, via a new
getExplicitMobileMode() that can answer "never chosen"; the per-device branches
below it are the defaults for that case.
* `.mobile-mode .list { width: 100% !important }` was outranked by
`.js-swimlane .list[style*="--list-width"] { width: var(--list-width) !important }`
- both !important, and the second more specific. It never showed on a phone (no
inline --list-width is emitted there), only in mobile mode on a desktop window.
The override repeats those three selectors prefixed with body.mobile-mode, and
keeps the :not(.list-collapsed) exclusion so a collapsed list stays 30px (#5892).
Also adds tests/jadeCompiles.test.cjs, which compiles every .jade with the SAME
compiler the build uses. Nothing else caught a broken template: the other suites read
.jade as text and grep it, so a file the compiler rejects still passes them all. It
was written after a `<body>` inside an indented `//-` comment block broke the build
here - the comment text is still lexed, so the angle brackets opened a tag that never
closed. All 107 templates parse in ~0.2s.
tests/headerHamburger.test.cjs asserted the hamburger sits inside the `.right` group,
which is exactly what moved; it now checks the new wrapper, its divider, and that
`order` still puts it last on a wide screen.
Tests: 1309 passing.
Thanks to xet7 !
The second header bar in mobile mode had nothing but icons - you could not tell
which board you were on. The title was hidden by
/* Hide the board title in mobile mode to match mobile view */
.mobile-mode .header-board-menu { display: none !important; }
which predates this work; it was not lost in the recent header changes, the markup
still rendered it.
It fits now, and on two rows by design: the title takes the WHOLE first row and the
button group - one flex item since the earlier header change - wraps to the second
row entire. Sharing one row would squeeze the title down to a few characters, which
is presumably why hiding it looked like the lesser evil before.
A long board name wraps rather than truncating: the name is how you know where you
are, so it is worth the extra line.
The rest of what is absent from that bar on a phone is unrelated and unchanged:
edit / visibility / watch / star / sort are not rendered at all under
`unless isMiniScreen`, and reappear as icon-only buttons in the right group.
Tests: the title must not be hidden by any rule, it takes a full row and wraps,
the button group takes the second row, and the two rules stay in row order. The
suite reads boardHeader.css for these - the mobile rules live there, not in the
header.css it otherwise reads.
Thanks to xet7 !
The page ended at the bottom of the form with nothing to scroll into.
Two <br> were already there for exactly this, with a comment saying so - they
just did nothing. `body` is `display: flex`, so a <br> at the layout root becomes
a FLEX ITEM: it gets blockified, has no content, and collapses to zero height.
Adding more would have added more nothing.
It is a real element now, .auth-bottom-space, 96px tall and flex:0 0 auto so it
cannot be shrunk back to nothing. That gives room to scroll the bottom of the
dialog - and the language selector under it - clear of the window edge, and of the
on-screen keyboard on a phone.
The height is px, not vh: this is spacing, and spacing must not change with the
window (tests/noViewportSpacing.test.cjs, from the previous commit).
Tests: the spacer exists, has a fixed height and is not shrinkable, and no bare
<br> sits at the layout root. Scoped to the root on purpose - the <br> nested
inside the h1 when the logo is hidden is in normal flow and works fine, so the
check must not condemn it.
Thanks to xet7 !
Reported on /sign-in and /sign-up: making the window taller made every element
taller and every gap wider; making it shorter shrank them. That is what vh does -
`padding: 3vh 3vw`, `margin-top: 6vh`, `min-height: 4.5vh` - the box is a
percentage of the WINDOW, so the page reflows continuously as you drag the edge
and the same layout looks different on every screen.
It was not only those two pages. 355 such values across 24 stylesheets, on
padding, margin, gap, height, line-height, font-size, border-radius and
box-shadow. They are now the pixel sizes they rendered at on the window they were
tuned for (1vh -> 9px, 1vw -> 14px), so each page looks as it did at that size and
stays that size everywhere else.
Two of them were documented bugs already: minicard.css carries two comments
explaining that the global `.viewer { min-height: 2.5vh }` "reserves a big empty
band under a one-line title, so half of every minicard was white space" on tall
screens. That floor is 22px now, and the modal body's 20vh is 180px.
Viewport units are still right for three things and are kept: a full-viewport box
(100vh/100vw), a CAP that stops content overflowing a small screen (min(), max(),
clamp()), and max-/min-width limits. 274 such uses remain, all deliberate.
The conversion was a token substitution - it cannot move or delete a rule - and
brace balance was asserted unchanged for every file before writing it.
Tests: tests/noViewportSpacing.test.cjs scans every stylesheet under client/ and
fails on any size or spacing measured in vh/vw, while still permitting the three
legitimate shapes (it checks both directions). It blanks block comments first, so
the two minicard.css comments ABOUT this bug are not reported as uses of it. One
existing test pinned the literal `2.5vh` global floor; it now pins a px floor, and
the dependency it documents - that the minicard override compensates for a global
floor - is unchanged.
Thanks to xet7 !
A handler left registered on a removed template threw at module load, which
stopped every later module in the client bundle - including the one that
registers the passwordInput template - so both password fields rendered as
nothing on Sign In and Register.
Thanks to xet7 !
My own regression, and a bad one: the login form had no password input.
When the Accounts pane was removed from Admin Panel / Settings - its three
settings having moved to Email and Login - its save handler was left registered on
the template that went with it:
Template.accountSettings.events({ ... }) // accountSettings no longer exists
That throws at MODULE LOAD, and because it throws, no module after it in the
client graph runs. client/features/users.js never executed, so passwordInput.jade
was never registered, and useraccounts logged
[UserAccounts] Warning no template passwordInput found!
then rendered nothing for the two fields that use it - password and
password_again. One dead reference in the Admin Panel took out the login form for
everyone.
The handler moved to Template.setting, which renders the Login pane its button
lives in.
Why nothing caught it: the file parses, every unit test passed, and the failure
only ever appears in a browser console. So the guard is new -
tests/templateHandlersExist.test.cjs walks every .js under client/components and
asserts each Template.X.events/helpers/onCreated/onRendered/onDestroyed has a
matching template(name="X") in some .jade. It ignores commented-out code (there is
a Template.cards.events() in a comment in minicard.js) and package-provided
templates. It fails on the pre-fix file.
Diagnosis notes, since "password field is missing" points nowhere near the Admin
Panel: the field was correctly registered - removeField returns the field object
and it is in addFields - and the compiled passwordInput template WAS in the served
bundle. What it was not was executed. The console error naming
Template.accountSettings is what tied the two ends together.
Thanks to xet7 !
It was a top-level Admin Panel page with its own shell, its own left menu and its
own route. It is one entry in the Settings menu now, between Accessibility and
PWA.
The whole page template had to become the pane, not just its table. The state that
feeds the table - the subscription, the search, the infinite scrolling, the count -
lived on Template.translation, and Template.translationGeneral reads it from
there. Moving only the table would have left it looking up state on a parent that
no longer renders it, and the pane would have shown an empty table with no error.
So Template.translation became Template.translationSettings, keeping its
onCreated, helpers and events together with the markup that needs them.
Two things it no longer needs: its own left menu (Settings provides one) and the
menu handler that toggled translationSetting - a pane is either rendered or not.
The /translation URL still resolves. It redirects to Settings rather than being
deleted, so an admin with a bookmark lands where the pane now lives instead of on
a template that no longer exists.
Tests: it is an entry in the Settings menu and Settings renders the pane; the
top-level tab and its active-helper are gone; the state moved with the markup
(Template.translation must no longer exist); and the route redirects rather than
rendering the removed template. The leftMenu suite no longer counts Translation as
a page with a menu of its own - it is one entry in another page's menu now.
Thanks to xet7 !
The last loose end of the People conversion. Its search box, its show-filter
dropdown, its "Unlock all users" and "Add / Remove Teams" buttons and its user
count lived in the PAGE HEADER, a different template from the table they act on.
They are the shared controls row now - the same slots this design gained FROM
People a few commits ago, finally used by it.
Its separate Search BUTTON is gone. Every table page searches on Enter, and a
second way to search is exactly the divergence this design removes.
Three things had to change with them, not just move:
- The search term is STATE (peopleSearchTerm) instead of being read back out of
$('#searchInput') - that id lived in the other template and no longer exists, so
filterPeople() would have searched for undefined.
- "Unlock all users" was a handler BODY. It is an instance method now, called by
the shared action handler via data-action, because the button is no longer
identified by its own id.
- The filter reset on render poked $('#userFilterSelect').val('all'). The shared
row renders the select from userFilterType, so it sets the state instead; the
old code would have silently done nothing.
All three handlers are scoped to the open pane, like the pager: every People pane
renders inside one template and they all carry the same shared classes.
Tests: none of the five removed ids survives in the header, the filter and actions
are declared to the shared row, the search term is state, the reset sets state,
and each of the three handlers is scoped to people-setting.
Thanks to xet7 !
Locked users is a form of numeric lockout settings with a Save button, Roles is a
checkbox list, and Shared templates is a checkbox list of scopes. None has a
paginated set of rows, so this design does not apply to them - forcing it would
only wrap a form in a table. They are listed with that reason so the next person
does not read the code to find out, or convert them by mistake.
That completes People: all FOUR of its table panes - Domains, Organizations,
Teams and People - render through the shared table page, and its three non-table
panes are documented as out of scope. The old entry asking "what converting it
would take" is answered and replaced.
One loose end stays recorded, as wiring rather than design: People's search box,
filter dropdown and two action buttons still live in the page header rather than
the shared controls row. The slots for all three exist - they were added to this
design FROM People - and its separate Search button should go when they move,
since every table page searches on Enter.
Tests: the three panes are listed with "not tables" as the reason, and none of
them renders a table page in the code - so the doc cannot drift from what is
there, in either direction.
Thanks to xet7 !
Fourth and last of People's table panes. Interactive rows again (rowTemplate) and
two template headers - the new-user row and the select-all checkbox. Its
.people-pagination rules are gone from both stylesheets, so NO People pane keeps a
pager of its own any more; all four use the shared, themed one.
The page of users is now one query. peopleDocs() is shared by the table context
and the old peopleList helper, instead of the same find() being written twice, and
it still must not re-slice: the 'people' publication already applies limit/skip
sorted createdAt:-1, and re-slicing it is what once left page 2 showing a single
stray doc - the admin's own user record, always in minimongo - with later pages
empty. A test pins both.
The Add/Remove Teams panel stays outside the table page: it is a panel this pane
opens, not part of the table.
All four table panes now share ONE scoped pager pair, switching on the open pane -
the only shape that works here, since every pane renders inside the same template
and duplicate keys in one event map would overwrite each other.
Remaining: Locked users, Roles and Shared templates. The last two still do not
look like tables at all - Roles is a checkbox list with a Save button - so they
may belong in the "does not use this design" list rather than converted.
Not yet moved: People's search box, its filter dropdown and its two action buttons
still live in the page header rather than the shared controls row. The slots for
them exist; wiring them across is the remaining step for this pane.
Thanks to xet7 !
Same shape as Organizations, so the same two slots: a rowTemplate for its
interactive rows and three headerTemplate columns for the select-all pairs. 1857
characters of its own table markup gone, plus its .team-pagination rules from both
stylesheets. Its three feature headers share ONE template parameterised by
feature, as Organizations' do.
Teams gains a working PREV button. It had one in its markup and no handler behind
it - paging backwards was silently dead - and folding both panes into a single
scoped handler pair fixed that on the way past.
That folding was forced, not chosen: every People pane renders inside the same
template and the shared page gives them all the same control classes, so a second
handler for the same selector would be a duplicate key in one event map and simply
overwrite the first. One pair now switches on the open pane.
Tests: Teams renders the shared page and keeps no table markup, uses both slots,
pages backwards, and there is exactly ONE prev handler. The uiDensity guard that
pins these headers as compact icon links was updated for the team half the same
way as the org half - it matches the parameterised markup and separately checks
all three features still have a header.
I ran the full suite BEFORE committing this time. The previous commit went in red
because I chained the run and the commit in one command; that guard's team half
was the failure it hid.
Four panes remain: People, Locked users, Roles and Shared templates.
Thanks to xet7 !
It pinned the org select-all links by their LITERAL data-feature values. The three
copies of that markup are now one shared header template parameterised by feature,
rendered through the table page's headerTemplate slot, so the literal match could
not hold. The intent - compact icon links, never full-text ones - is unchanged: it
now matches the parameterised markup and separately checks all three features still
have a header, so a dropped column would still fail.
This should have been in the previous commit. I committed it before reading the
full-suite result; the suite was red for one commit.
Thanks to xet7 !
Organizations could not be expressed as a column spec: its rows carry inline
checkboxes and edit links, and three of its headers carry a select-all pair. The
design gains two slots rather than those panes staying outside it:
- rowTemplate + docs - the page supplies a template and one data context per row,
and owns its <tr>. It is then responsible for matching the column count: the
guarantee that a row can never be shorter than the header holds for the CELLS
form only, and the doc says so.
- headerTemplate + headerData on a column - the <th> still belongs to the shared
template; only its contents come from the page.
Everything else stays shared either way: layout, paging, search, the themed pager,
the total. The doc says to prefer the column spec and reach for these only when a
pane is genuinely interactive.
Organizations now renders through the shared page - 1826 characters of its own
table markup gone, plus its .org-pagination rules from both stylesheets, since it
uses the shared pager. Its three feature headers share ONE new template
parameterised by feature, instead of three copies of the select-all pair.
One thing the conversion forced: all of People's panes render inside the SAME
template, so a handler bound to a shared control class fires for every converted
pane at once. The org pager is scoped to the open pane via activeMenuId - Domains
was unaffected because its handlers live on its own child template.
Tests: the two slots exist and the plain column path is unchanged; Organizations
renders the shared page, keeps no table markup, uses both slots, and scopes its
pager. Two doc/test pairs updated to say "Domains and Organizations".
Five panes remain: Teams, People, Locked users, Roles, Shared templates.
Thanks to xet7 !
First of People's seven panes converted to docs/Design/Page/Table.md. Its own
controls row, pagination markup and table - 891 characters of jade - became one
+tablePage(tablePageData) plus a two-column spec, and 56 lines of pane-specific
CSS are gone: the layout comes from tablePage.css and the pager colours from
paginationControls.css, like every other pager.
Its separate Search BUTTON is dropped, as the design says: every table page
searches on Enter, and a second way to search is exactly the divergence this
design removes. The handlers keep their behaviour but move to the shared control
classes, so the pane needs no markup, no CSS and no pager rules of its own -
.domain-pagination and .domain-page-info had no users left and are removed from
the shared pager stylesheet.
The pane also gains the result total for free: it is one of the controls-row
features adopted from People itself a few commits ago.
Docs: the "Pages that do not use this design" entry now reads "People - six of
its seven panes" and records that Domains is converted; Domains is listed among
the pages that DO use the design.
Tests: the entry must say Domains is converted, and that pane must render the
shared template and keep no markup of its own - so the doc cannot claim a
conversion that did not happen, nor stay silent about one that did. A test that
listed Domains among the panes with their own themed pager was updated; it caught
the now-dead CSS, which is what it was for.
Six panes remain: Organizations, Teams, People, Locked users, Roles and Shared
templates.
Thanks to xet7 !
Two follow-ups from the Admin Panel / Settings reorganisation, recorded with
their reasons so whoever picks them up knows the scope:
- The docs and the website still describe the OLD layout - the Layout pane (now
PWA), the Accounts pane (removed), the previous homes of about a dozen settings,
and the two renames (Boards visibility -> Visibility, Registration -> Login).
The settings moved and are tested; only the prose is behind.
- docs/Features/ does not mirror the current menu, so a menu path cannot be
mapped to a docs path. Restructuring it is a rename-and-relink sweep: the design
docs under docs/Design/Page/ link into those folders and their tests assert the
links resolve, so both have to move in one commit.
Thanks to xet7 !
The pane keeps what makes an instance installable - the custom head tags, the web
app manifest and assetlinks.json - and everything else moves to where it belongs:
- branding to Visibility: product name, hide logo, login logo image/link, text
below the login logo, the three top-left corner logo fields, the custom help
link and the automatic linked URL schemes;
- the OIDC button text to Login, with the rest of the sign-in configuration.
PWA is an acronym, not a translated string, so the menu entry and the pane header
use a LITERAL label - the same support the shared left menu grew for the Sandstorm
entry in Attachments. No i18n key was invented for it.
js-save-layout is gone with its button. Its fields are written by the panes that
now show them, each only when its input is actually rendered, so no pane can blank
a setting it is not displaying. The product name still retitles the page.
This redoes, correctly, the work I reverted after corrupting this file: the block
extractor now works on LINE ranges bounded by the template end, instead of slicing
to "the next li" - which ran past the template and dragged the announcement pane's
markup into Visibility. The 16 top-level blocks are enumerated with their exact
boundaries before anything moves, and the template count is checked afterwards.
Tests: the pane is pwaSettings and keeps exactly the four PWA blocks; branding and
sign-in settings are NOT in it; PWA is a literal label with no i18n key; the
branding group is in Visibility with a guarded save; and js-save-layout is gone
entirely, so no handler is left reading inputs that now live elsewhere.
Thanks to xet7 !
"Display Authentication Method" (Yes/No) and the default-method dropdown move to
Login, where the rest of the sign-in configuration now lives. "Wait Spinner"
moves to Visibility.
The empty-value guard travelled with the dropdown. Its value can be '' when
nothing is chosen, and writing that over the REQUIRED defaultAuthenticationMethod
string fails validation silently - which is why resolveDefaultAuthenticationMethod
falls back to the stored method. Left behind in the Layout save it would have
protected nothing.
Wait Spinner is a text field, so it carried the erase-on-save trap: the Layout
save read $('#spinnerName').val() || '', which is '' once the input is elsewhere.
Both new homes write only what is actually on screen.
One of my own tests was wrong rather than the code: it sliced the Layout handler
'up to the next handler', which swallowed the following handler whole and made
'Layout no longer writes X' fail on the pane that legitimately does write X. It
now slices a handler's own body, and a new check sweeps every field that has left
Layout in this series.
Thanks to xet7 !
- Support -> Visibility. All of it: the /support link, the "Support page enabled"
toggle AND the content editor that toggle controls (public flag, title, text,
its own Save). Moving only the two visible rows would have left the editor
behind in Layout, controlled by a checkbox on another page.
- Email domain name -> Email.
- Custom legal notice page URL -> Visibility.
The two text fields carried the same trap as the earlier moves, in a worse form.
The Layout save read them with
($('#mailDomainNamevalue').val() || '').trim()
Once the input is not in that pane, .val() is undefined, the fallback makes it
'', and pressing Save on Layout would have written an EMPTY string over the
stored domain name and legal notice URL - silently erasing both. Those reads and
their $set keys are removed from the Layout save, and their new homes write each
field only when its input is actually on screen.
Support needed no handler change: js-toggle-support saves on click and
js-support-save reads inputs that moved with it.
Tests: each item is in its new pane and gone from Layout, the whole Support
feature moved together, the Layout save no longer touches either text field, and
both new saves guard on the input existing.
Thanks to xet7 !
"Allow Email Change" moves to Email; "Allow Username Change" and "Allow users to
self delete their account" move to Login. All three were in the Accounts pane.
The helpers move with them. A radio is bound to {{#if allowEmailChange}}, and a
helper the HOST template does not have renders as false - the setting would show
as "No" whatever its stored value. They are one shared object now, registered on
Template.email and on Template.setting (which hosts the Login pane).
Saving is split the same way: Email's existing Save takes allowEmailChange, and
Login gets a Save for the other two. Both write only what they actually found on
screen - the same guard as the earlier moves, so a radio that is not rendered can
never be written as false.
That left the Accounts pane with nothing but a Save button, so the pane, its menu
entry, its state, its helper and its pane header are removed rather than left as
an empty page. The accountSettings SUBSCRIPTION stays: the settings still live in
that collection, only where they are shown changed.
Tests: each setting is in its new pane, each host pane has a Save that reaches it,
the empty pane and every reference to it are gone, the helpers are registered on
both host templates, the saves skip a radio they did not find, and the
subscription remains.
Thanks to xet7 !
The pane holds the whole sign-in configuration - default authentication method,
password login, self-registration, forgot-password - so "Registration" described
only part of it.
Uses the EXISTING "login" key ("Login"), as asked: every language that already
translates it is covered and there is no new string to translate. The pane id
stays registration-setting, so nothing inside the pane loses its translations.
That is the same rule the "Visibility" rename followed one commit ago, for the
opposite reason: no key meaning "Visibility" existed, so a new one had to be
added rather than editing tableVisibilityMode in place, which is translated in 141
languages as "Boards visibility".
Tests: both renames are pinned - the entries point at keys that exist in
en.i18n.json, and the pane ids are unchanged.
Thanks to xet7 !
"Don't show the board activities on all boards" was a BUTTON in the Layout pane
that called setAllBoardsHideActivities(), which bulk-set showActivities:false on
EVERY board document. That was wrong twice over: it overwrote each board's own
value for good, so it could never be undone, and it did nothing at all for boards
created afterwards.
It is now one global setting - Settings.hideBoardActivitiesOnAllBoards - with its
own pane, Admin Panel / Settings / Hide board activities on all boards, saved as
Yes/No like the other instance-wide switches. The activity feed reads it ONCE, in
_showActivities(), before any per-board or per-card value: when it is on, no board
shows activities; when it is off, every board's own setting applies again,
unharmed. Boards are never written to.
The server method is removed rather than left callable. It was unreachable from
the UI after this change and its only effect was the destructive write.
Also, per the follow-up: the pane previously labelled "Boards visibility" is now
just "Visibility". The label points at a NEW i18n key rather than changing the
value of tableVisibilityMode, because that key is already translated into 141
languages as "Boards visibility" - editing the English source in place would have
left every one of those translations silently saying the old thing. en.i18n.json
had no key meaning "Visibility", so one was added; the pane id and its own key are
untouched, so the pane's contents keep their translations.
Tests: tests/boardsVisibilitySettings.test.cjs now also covers the activities
move - its own pane exists, the Layout button and its handler are gone, the save
writes ONE global setting and never a board document, a missing radio is skipped
rather than saved as false, the schema field exists, and the read side consults
the global flag BEFORE any per-board value. Plus the pane label check follows the
rename.
Thanks to xet7 !
"Hide card counter list on All Boards" and "Hide board member list on All Boards"
were in the Layout pane, which is about logos, links and head tags. They are about
what All Boards SHOWS, which is what the Boards visibility pane is for - its i18n
key is tableVisibilityMode, but the label admins see is "Boards visibility". Both
settings now sit there, saved by that pane's Save button.
The move had a trap. The Layout save read them as
$('input[name=hideCardCounterList]:checked').val() === 'true'
Once the radios are no longer in the Layout pane, :checked matches nothing,
.val() is undefined, the comparison yields FALSE, and pressing Save on Layout
would silently turn BOTH settings off - a data change from a pane that no longer
shows them. So the reads and the two $set keys are removed from the Layout save,
not just the markup.
The new save guards the same class of mistake from the other side: it writes each
flag only when its radio was actually found, and sends no update at all when it
found neither. The two flags live in Settings while the pane's own
allowPrivateOnly lives in TableVisibilityModeSettings, so this is a second,
separate write.
The i18n keys are untouched - the strings only moved - so no translation is lost.
Tests: tests/boardsVisibilitySettings.test.cjs pins that the pane it targets is
really the one labelled "Boards visibility", that both settings are in it and
gone from Layout, that the Layout save no longer writes them (the trap), that the
new save is guarded against writing a value it did not find, and that the i18n
keys are unchanged. It fails on the pre-move code.
Thanks to xet7 !
The last of the seven. 2525 characters of menu markup became one
+leftMenu(menuItems); Attachments already tracked the open pane in activeSection,
so nothing had to be derived, and its single click handler is untouched - the
shared template puts js-attachments-menu on every entry alongside the shared
class.
One template addition: the Sandstorm entry is a proper noun, not a translated
string, so an item may now carry a literal `label` where the others carry a
`labelKey`. The Sandstorm-only condition survives as data, a null the builder
drops, rather than markup wrapped in `if isSandstorm`.
All seven Admin Panel pages now render the same menu from a data list. Across
them: 8393 characters of duplicated markup gone, 44 entries described as data,
and 19 near-identical click handlers collapsed to 7 - one per page.
Tests: a check that ALL seven render the shared menu and none keeps .side-menu
markup of its own - the design is only worth having if nothing is left outside it
- plus the Sandstorm entry and the literal-label fallback.
Remaining: People's seven pane tables still need converting to Table.md.
Thanks to xet7 !
Sixth page converted to docs/Design/Page/Left-Menu.md. 1067 characters of menu
markup became one +leftMenu(menuItems), and the seven near-identical
'click a.js-<pane>-menu' handlers became one 'click .js-left-menu-item'.
People tracked the open pane by toggling a DOM class, which is why it was left
until now: it needed an active id first. switchMenu already derived all seven
pane booleans from the clicked data-id, so the id was there - it just was not
kept. It is now this.activeMenuId, starting at 'org-setting', which is the pane
orgSetting already started true for, so the page opens exactly as before.
With the active row rendered from that state, the manual removeClass/addClass is
gone - it would have fought the next re-render - and the "already open" guard
compares ids instead of reading a DOM class. data-id is resolved from the anchor
rather than event.target, which may be the icon inside it.
The per-pane extras survive the collapse: switching to Organizations, Teams or
People still resets that pane to page 1 and refreshes its total.
Same styling: Locked users keeps the red lock it always had, through the coloured
icon wrapper the shared template supports for exactly this case.
Tests: the page renders the shared menu, keeps no .side-menu markup, builds its
entries through the shared helper, has none of the seven old handlers and exactly
one new one, still runs the three per-pane refreshes, holds the open pane in
state, and keeps the red lock.
Remaining for Left-Menu.md: Attachments. Remaining for Table.md: People's seven
pane tables.
Thanks to xet7 !
The three features that kept Admin Panel / People off this design are now part of
it, and they are ON by default - there is no enabling flag. A page that supplies a
filter or an action gets it rendered, and the total is shown whenever the page
knows one:
filters: buildFilters([{ id, labelKey, options: [{ value, labelKey }] }], current)
actions: buildActions([{ id, labelKey, icon, cls }])
total: <number> (+ optional totalLabelKey)
They are general - a Boards or Cards report wants a filter and a total as much as
People does - so they belong in the one template rather than in a per-page copy.
The controls row now reads: search, filters, actions, total, pagination.
A page identifies which control was used by its data attribute (data-filter,
data-action), so this adds no new handler pattern: the same one-handler-per-page
rule as the search and the pager.
The option matching `current` is selected as STRINGS, so a numeric filter value
still selects. The total sits with the controls, not in the table, because it
counts the whole result set rather than the page, and inherits its colour so it
stays readable on a dark theme.
Tests: the two new helpers (including junk input - a filter with no options
renders an empty select rather than crashing), that the four parts appear in
reading order between the search field and the pagination, that there is NO
opt-in flag, and that the doc says so.
One earlier guard needed fixing rather than the code: "the table page stylesheet
does not restate button colours" sliced the CSS by POSITION, so the new rules
landed inside the slice and tripped it. It now matches by selector, which is what
it always meant.
NOT done: People itself still renders its own markup. Its seven panes
(Organizations, Teams, People, Domains, Locked users, Roles, Shared templates)
are seven tables with their own columns and handlers, and converting them is a
larger piece of work than adding these features was. The blocker recorded in
Table.md is now gone, so that conversion is unblocked - the "Pages that do not
use this design" entry stays until it is actually done.
Thanks to xet7 !
A page with a paginated table that is not built from this design is a gap. Left
unwritten, the next person re-derives the answer by reading the code - or worse,
copies a few of this design's classes into it and leaves it half-converted, which
is exactly how the ten report pages drifted apart before.
People (Admin Panel / People) is the one such page. It predates this design and
has its own controls and table markup, one set per pane - Organizations, Teams,
People, Domains, Locked users, Roles, Shared templates - so it is several tables
on one page rather than one. It also carries four things this template has no
slot for: a filter dropdown (all / locked / active / inactive / admin), action
buttons ("Unlock all users", "Add / Remove Teams"), a result count beside the
controls, and a separate Search button where a table page searches on Enter.
The entry also records what People ALREADY shares, so the remaining work is not
overstated: it pages server-side with limit/skip exactly as this design requires,
and its prev/next buttons are themed by the shared pager stylesheet through the
.people-pagination class, so it already follows the per-user theme and the WeKan
default. What is missing is on this side - optional slots in the controls row for
a filter, extra actions and a total, rendered only when a page supplies them.
Those are general enough for a Boards or Cards report to use, so they belong in
the shared template rather than in a per-page copy.
Tests: the section must exist, must come before the pages that DO use the design,
must list People with a reason that actually explains, and - so the entry cannot
quietly go stale - People must still have none of this design's markup. If it
ever gains it, the test fails and the page moves to the other section.
Thanks to xet7 !
Four more pages converted to docs/Design/Page/Left-Menu.md. Their menus are data
now, not markup: 1956 + 724 + 189 + 184 characters of hand-written .side-menu
blocks became one +leftMenu(menuItems) each.
Same styling: all four kept the icon shape they had. Settings and Features pass
emoji:true, which renders the empty span.emoji-icon they always had before the
icon; Translation and Info render the bare i.fa they always had.
Settings needed one derivation. It tracks the open pane with eight separate
ReactiveVars rather than an active id, so activeSettingId() maps them to the id
the menu highlights - no behaviour change, and the menu still cannot highlight two
rows. Its Sandstorm exception survives as data: the e-mail entry is a null the
builder drops, instead of markup wrapped in `unless isSandstorm`.
Each page keeps its own single click handler, so their behaviour is untouched -
the shared template puts both js-left-menu-item and the page's own class on every
entry.
Tests: tests/leftMenu.test.cjs checks all four render the shared menu, keep no
.side-menu markup of their own, build through the shared helper and keep their
handler class; and that Settings still has its Sandstorm exception and maps every
one of its eight panes to an id (an unmapped pane would never highlight).
Remaining: People and Attachments. Both track the open pane by toggling a DOM
class rather than in state, so they need an active-id var first.
Thanks to xet7 !
First page converted to docs/Design/Page/Left-Menu.md. Its thirteen entries were
six lines of markup each plus, for twelve of them, an identical click handler.
They are now a data list:
{ id, icon, labelKey } and { separator: true }
built by buildMenuItems() and rendered by the one leftMenu template. 1895
characters of markup in adminReports.jade became a single +leftMenu(menuItems).
Same styling, deliberately: the shared template reproduces all three icon shapes
the Admin Panel pages already used, so a conversion changes no pixel - an empty
span.emoji-icon before the icon (Settings, Features), the icon inside a coloured
span.emoji-icon (People / Locked users), or a bare i.fa (Problems, People,
Translation, Info). Problems uses the bare shape it had.
The twelve 'click a.js-report-<name>' handlers, all of which called switchMenu,
are one 'click .js-left-menu-item'. switchMenu no longer toggles the active class
by hand either: the active row is rendered from activeReport, so the manual
removeClass/addClass would have fought the next re-render. Its "already open"
guard now compares ids instead of reading a DOM class, and it resolves data-id
from the anchor rather than event.target, which may be the icon inside it.
Three suites looked for the menu ids in adminReports.jade; the menu is DATA now,
so they read the .js. Same intent, right file.
Tests: tests/leftMenu.test.cjs gains the conversion checks - the page renders the
shared menu, keeps no .side-menu markup of its own, builds its entries through
the shared helper, has exactly one menu handler and no manual active-class
toggling, and the three icon shapes are reproduced.
Still to convert: Settings, People, Features, Attachments, Translation and Info.
Settings, Features and the two single-entry pages are the same mechanical swap.
People and Attachments additionally need an active-id reactive var, because they
track the open pane by toggling a DOM class rather than in state.
Thanks to xet7 !
docs/Design/Table-Page.md -> docs/Design/Page/Table.md, with every reference
updated: the three design docs that link to it (History, CPU-usage, Recovery),
the code comments in the shared template, stylesheet and helpers, and the four
test suites that read it. Its own link to History.md is re-based, since the file
is one level deeper now.
docs/Design/Page/Left-Menu.md is the second page design: the menu beside the
content on every Admin Panel page. It records what those seven menus share, which
pages use it, the entry shape, and how a page adds one.
Which side it is on is part of the design, not an accident of the markup: for a
left-to-right language the menu is on the LEFT with the content to its right; for
a right-to-left language the whole panel MIRRORS - the menu is on the right, the
content to its left, and inside each entry the icon and label mirror too. That
works only through the document direction plus logical CSS, so the doc says to
never write left/right/margin-left/padding-left for this menu.
Checking that turned up two places where the current CSS did exactly that:
- .side-menu had `box-shadow: inset -0.2vh ...`. An inset shadow offset on the X
axis is a PHYSICAL direction and does not mirror, so it shaded the wrong inner
edge once the menu moved to the right. The X offset is dropped.
- the entries used `padding: 1.3vh 0 1.3vh 1.3vw`, i.e. padding-LEFT, so under an
RTL language the indent stayed on the left - the outer edge of a right-hand
menu. Now padding-block + padding-inline-start.
Theme: the menu was entirely hard-coded greys. Most of it stays neutral on
purpose - it is chrome, and tinting the whole card would fight the content beside
it - but the entry you are ON now takes the per-user theme accent (Member
Settings -> Change color sets --theme-accent on :root), with `inherit` as the
fallback so the WeKan default look is byte-for-byte unchanged when no colour is
chosen. No brand colour is hard-coded in the menu.
The shared pieces are in place: client/components/settings/leftMenu.jade renders
the menu from an item list, and models/lib/leftMenu.js turns (items, activeId)
into it - marking exactly ONE entry active, dropping conditional holes, and
supporting group separators.
Tests: tests/leftMenu.test.cjs is the one suite for this design - the pure
helpers, the template, the mirroring, the theming, the shared narrow-window
stacking, and that every path in the doc's related-files table exists.
NOT done yet: the seven Admin Panel templates still render their own copy of the
menu markup. Converting them to +leftMenu is the next step; the design, the
template, the helpers and the tests it will be checked against are ready.
Thanks to xet7 !
tests/adminReportsPagination.test.cjs asserted against the same pages as
tests/tablePage.test.cjs from a second file - the same split this change removed
from the app code, and written when each report still had its own markup,
controls row and stylesheet. It is merged into tests/tablePage.test.cjs, which is
now the one suite for the design: the pure helpers, the template, the layout, the
themed pager, the server-side index-backed paging, and the doc.
Its last three checks cover the OTHER pagers (People/Org/Team/Domain, the board
Table view, Translation). Those are not table pages, but they share the themed
pager stylesheet the design lists, so a change there reaches them too - they are
kept, next to what they depend on.
Deduplicated on the way in: the merged "pagination controls use
var(--theme-accent)" was a weaker copy of the check above it, which already pins
all five button states; its two unique assertions were folded in and the copy
dropped. 10 + 22 checks -> 31, no coverage lost.
Two guards were pointed at the wrong file after the refactor:
- fileNameDisplay's "the invisible-character filter is fully removed" read only
adminReports.jade, which no longer holds ANY report markup - so it passed no
matter what. It now reads the shared template too.
- Table-Page.md's related-files table still listed the deleted test. The suite's
own "every path in this table exists" check caught it; the row now describes
the combined suite.
Thanks to xet7 !
Checking how the table page's buttons are themed turned up two problems.
First, a bug I introduced with the shared table page: tablePage.css restated the
pagination button colours itself, and only for the base state, :hover and
.disabled. WeKan already has ONE stylesheet for every prev/next pager in the app,
client/components/main/paginationControls.css, and it spells out :hover, :focus,
:active AND :active:hover deliberately - because the global button rules in
forms.css set those same states from --theme-accent with a BLACK / dark-grey
fallback, at equal or higher specificity:
button { background: var(--theme-accent, #000) }
button:focus { background: var(--theme-accent, #222) }
button:active { background: var(--theme-accent, #111) }
button:active:hover { background: #e6e6e6 }
A partial copy looks right until the button is CLICKED and then loses: pressing
"next" on a table page would have left a black button sitting there until it lost
focus - exactly the regression that stylesheet was written to prevent.
.table-page-pagination / .table-page-page-info are now listed in it, and
tablePage.css carries layout only.
Second, trimming adminReports.css in the previous commit removed the
.admin-report-controls layout, which Archived boards also used - so its search +
pagination row lost its flex layout. Archived boards now uses the shared controls
classes (its js- handlers are unchanged), which restores the layout and gives it
the same themed pager. .admin-report-pagination / .admin-event-pagination had no
users left afterwards and are gone from the pager stylesheet.
So a table page never invents a colour: the buttons and the "3 / 42" counter
follow the per-user theme (Member Settings -> Change color sets --theme-accent on
:root) and fall back to the WeKan default blue #01628c when no custom colour is
chosen, and the counter uses color: inherit so it stays readable on a dark theme.
Docs: Table-Page.md gains a Theme section saying exactly that, with the forms.css
specificity trap written down so the colours are not copied back into a page
stylesheet, and paginationControls.css + forms.css are added to the related-files
table.
Tests: the shared pager must cover the table page class in all five states with
the accent + WeKan-blue fallback; tablePage.css must not set background, color or
border on the pager; and the design doc must document the theming.
Thanks to xet7 !
A File Path / File Type / Description table of all sixteen files that make a
table page work: the shared template, stylesheet and pure helpers; the Admin
Panel wiring; the client import list (a file that is never imported is simply not
loaded, which is its own class of bug); the six report publications and their
count methods; the event-log model behind the Security / Speed / Tests / CPU
streams; and the two test suites.
The old two-column "Where the code is" section at the bottom listed a subset of
the same files and is removed rather than kept in parallel - a reference table
that exists twice is one that goes out of date once.
Tests: tablePage.test.cjs checks the table has those three columns, that every
path it lists exists on disk, that the shared implementation is among them, and
that no file is listed twice. A renamed or moved file now fails the suite instead
of leaving the page quietly pointing at nothing.
Thanks to xet7 !
Upgrading a Snap from 6.09 to 10.37 migrated successfully and then served 503
until the admin ran `snap restart wekan` by hand. WeKan sat in its startup loop
printing "MongoDB not ready yet, retrying in 5 seconds..." against a MongoDB the
migration had just shut down for good.
mongodb-control ends with `exec bash $SNAP/bin/migration-control`, so
migration-control IS the wekan.mongodb service process. The switch to FerretDB
ran, in this order:
snapctl start --enable <snap>.ferretdb
snapctl restart <snap>.ferretdb
snapctl stop --disable <snap>.mongodb <- stops the service THIS script is
snapctl restart <snap>.wekan running in: SIGTERM, dead here
so the restart that hands WeKan over to FerretDB never ran. The reporter's log
shows it exactly: "Migration succeeded. Switching to FerretDB (SQLite); MongoDB
will be shut down." at 13:15:12, systemd stopping snap.wekan.mongodb.service and
"[migration] Interrupted (snap refresh, stop or reboot)" one second later, then
minutes of wekan.wekan waiting for a MongoDB that was gone. The comment above
that block already noted the service can terminate us - the restart just needed
to be on the other side of it.
WeKan is now restarted onto FerretDB BEFORE MongoDB is stopped, and the stop is
the last command in the switch. The traps are disarmed just before it, so being
stopped there no longer logs "Interrupted (snap refresh, stop or reboot)" after a
migration that in fact SUCCEEDED, nor runs cleanup for a finished run.
The restart must not be the only way out of that loop either, since it is the
last act of a script being killed: wekan-control's MongoDB wait now re-reads the
live `database` setting each round and re-execs itself when it has become
ferretdb. A migration that finishes while WeKan waits therefore recovers on its
own within five seconds, with no admin action.
mongodb-control's equivalent switch ("a completed FerretDB migration exists")
already had the correct order; a test now pins that too.
The high FerretDB CPU right after migration is a separate matter and is expected:
WeKan creates its indexes on first start against the new database, and in this
report WeKan never reached FerretDB until the manual restart, so that work had
not even begun when the reporter looked.
Tests: tests/snapMigrationSwitchOrder.test.cjs pins the ordering, that no snapctl
command may follow the self-terminating stop, that the traps are disarmed first,
that the pre-switch verification still comes before any of it, and the
wekan-control self-recovery. It fails on the pre-fix scripts.
Thanks to S0QR2 and xet7 !
Fixes#6525,
Files, Rules, Boards, Cards, Impersonation, Recovery and the four event streams
(Security, Speed, Tests, CPU usage) were ten copies of the same page: the same
title + search + prev/next markup, the same currentPage/totalPages helper pair,
and the same click/keydown handlers, retyped with a different js- prefix each
time. They had drifted apart, and any layout fix had to be made ten times.
They now render through ONE template and differ only in a column list:
{ label | labelKey, value(doc), align, nowrap, cls, userId(doc), data(doc) }
- client/components/settings/tablePage.jade - title, optional status row,
controls, table. The row ORDER is defined here once.
- client/components/settings/tablePage.css - the layout.
- models/lib/tablePage.js - pure pageInfo() / buildRows() / buildHeader() /
columnWidthPercent(), unit-tested without a browser or a database.
adminReports.jade 349 -> 112 lines, its CSS 134 -> 53, ten templates -> four,
twelve page/total helpers -> none, twenty-four control handlers -> four.
Layout fixes, now made once and reaching every page:
- The table is width:100% with table-layout:fixed, so every column gets the SAME
percentage of the width and the table can never grow wider than the panel. With
the default auto layout one long id or file name widened the table past the
panel and pushed its right-hand columns outside the browser window.
- Cells wrap: overflow-wrap:anywhere breaks even an unbroken id, URL or file name
inside its column. Datetime columns opt out with nowrap.
- .table-page has min-width:0 / max-width:100% so it can shrink inside the flex
.main-body instead of setting a min-content floor; only the table's own wrapper
may scroll sideways, never the page.
- At <= 800px the side menu goes full width on top and the table sits BELOW it.
This deliberately overrides the older "always side by side, even on narrow
windows" rule, which on a phone left the table a few dozen pixels wide with its
right-hand columns unreachable. Above that width the menu keeps its place and
the table sits beside it.
- Rows top to bottom: title, status (the live CPU figure on the CPU usage page),
controls, table.
Paging still loads only the current page - the publications apply limit/skip -
and loadReport now takes that window from the SAME pageInfo() call that renders
"page X / N", so what is fetched and what is displayed cannot drift apart.
Docs: the shared design moves out of the History design doc into
docs/Design/Table-Page.md, which lists every page that uses it (table name, menu
path, description) per group. History.md, CPU-usage.md and Recovery.md now link
to it and keep only what is specific to them.
Tests: tests/tablePage.test.cjs (18) covers the pure helpers - including a page
that no longer exists clamping to a real one, and a short row never shifting the
columns - plus the layout rules the doc promises and the "one implementation"
guarantee. Four existing tests that pinned the old per-report markup were updated
to the new mechanism, same intent.
Thanks to xet7 !
`./pull-security-reports.sh` reported OK for every endpoint and then wrote empty
split files and blank counts:
Counts (open / closed):
CodeQuality/StandardFindings: / -
Dependabot/Vulnerabilities: / -
`gh api --paginate --slurp` returns ONE ARRAY PER PAGE, so a list endpoint arrives
as [[alert,...],[alert,...]]. Nothing flattened that, so `.[]` yielded PAGES, not
alerts, and every `select(.state == "open")` was applied to an array. jq failed,
its error went to /dev/null, and the `>` redirect left a 0-byte file - which is
not valid JSON, so every later step on it failed too and printed nothing. A
security report that quietly claims there is nothing to see is worse than one
that fails, so:
- fetch() now concatenates the pages into a single list, but only when EVERY
element is itself an array; endpoints returning one object (/repos/{o}/{r},
the SBOM, default-setup) are slurped to [ {...} ] and are left alone, because
their renders index .[0].
- split() writes through a temp file, keeps a valid empty ARRAY and the jq error
on failure, and warns in the summary instead of truncating the destination.
- the secret-scanning redaction validates the redacted copy before deleting the
file that still holds live secrets - it used to write nothing and delete the
source anyway - and now removes that file on the failure path as well.
- count() always prints a number, so the summary can no longer show a blank
column, and the closed column starts at "-" rather than an empty string.
The same shape also broke the newest-analysis lookup (`sort_by | last | .id`
over pages) and the codeql-databases dump; both come right with the flatten.
Verified offline with the fake-gh harness the README documents, replaying the
real fixtures from the failed run: code scanning 4 pages -> 392 alerts,
Dependabot 1 page -> 86, analyses 152 pages -> 15118, advisories -> 22, and the
splits land as 2 open code scanning / 386 closed and 2 open Dependabot / 83
closed, with no zero-byte file anywhere in the run.
Tests: tests/securityReportScript.test.cjs guards the flatten, the non-truncating
split, the redaction ordering and the count helper, and - when jq is installed -
runs the actual filters, including a check that select() on an array-of-pages
still fails, so the guard cannot quietly stop being what protects the split.
Thanks to xet7 !
Both are in test helpers, so neither is reachable by an attacker, but both are
genuinely wrong string handling and CodeQL rates the rule High.
Alert #428, tests/boardHeaderOneLine.test.cjs: the rule bodies were split with
`rule.split('{')` and the trailing brace removed with `body.replace('}', '')`,
which strips only the FIRST '}'. The block is now matched with a single regex
that captures selector and body as separate groups, so no brace ever ends up in
the text and there is nothing to strip. Verified the check still catches a
non-margin declaration in a button rule, and still ignores the h1's padding.
Alert #427, tests/testsAreRegistered.test.cjs: a file name was spliced into a
RegExp after escaping only dots (`stem.replace(/\./g, '\\.')`), leaving every
other metacharacter - the backslash above all - able to change the meaning of the
pattern. It now goes through an escapeRegExp() that escapes the full set
including the backslash itself.
Thanks to GitHub CodeQL (code scanning alerts #427 and #428) and xet7 !
brace-expansion 5.0.7 -> 5.0.8 (PR #6523) fixes CVE-2026-14257 / alert #119, High,
CVSS 7.5: expand() bounds the NUMBER of results but not their LENGTH, so chained
brace groups keep the count under the 100000 cap while every result grows one
character per group, and a ~7.5 KB input kills the Node process with a fatal,
uncatchable out-of-memory error. Unlike the postcss alert this one is a RUNTIME
dependency, reached transitively through minimatch.
postcss 8.5.15 -> 8.5.22 (PR #6522, already merged as 10af0bc2a) fixes
GHSA-r28c-9q8g-f849, High, CVSS 7.5: a path traversal in previous-source-map
auto-loading disclosed arbitrary .map files. Dev-only, via css-loader.
Both lock edits were checked against the npm registry (tarball integrity and
resolved URL match), and the brace-expansion one was reproduced locally with
`npm update brace-expansion --package-lock-only`, which produced a byte-identical
diff to the Dependabot PR. 5.0.8 also narrows engines.node to "20 || >=22"; WeKan
builds and ships on Node 24, so that is a no-op here.
elliptic (alert #55, CVE-2025-14505) stays as recorded in v10.14: no fixed version
exists upstream (latest is still 6.6.1, advisory patched version None). Noted here
that it is additionally unreachable - a dev-only polyfill under
@meteorjs/rspack -> node-stdlib-browser -> crypto-browserify, no WeKan client
module imports node crypto, and the built client bundle contains no elliptic,
secp256k1 or crypto-browserify code at all.
Thanks to xet7 !
On iPad landscape with a long board title, the controls were split across both
rows: the title kept the left group (edit, visibility, watch, star, sort) beside
it and only the right group (Filter / Search / view / dependencies /
multi-selection / hamburger) wrapped underneath.
That is what separate flex items do. The title, the left group, the centre group
and the right group were four children of the #header-main-bar flex row, so the
row filled with as many of them as fit and broke wherever it ran out - between the
left and the right group. The three button groups now live inside ONE wrapper,
.board-header-btns-group, so the row has just two items: the title and the
buttons. Either the buttons fit beside the title or the whole set moves down
together, under the title, which is what the report asked for.
A short title is unaffected: the wrapper's flex-basis is auto, so it measures as
its content width and only moves down when it genuinely does not fit - title and
buttons still share one line exactly as before. The wrapper keeps flex-wrap: wrap
so the groups can still break among themselves at widths where even the buttons
alone do not fit. The h1 gains min-width: 0 / max-width: 100% / overflow-wrap so a
title longer than the whole bar wraps inside the title instead of overflowing the
viewport (a flex item cannot shrink below min-content without min-width: 0).
The template change is a re-indent: every content line is unchanged, only its
indentation, plus the new wrapper and its comment.
exportHTML.js removed '#header-main-bar .board-header-btns' when exporting a board
to HTML; it now removes the wrapper as well, so the export is not left with an
empty div where the buttons were.
Tests: tests/boardHeaderOneLine.test.cjs gains checks that all three groups are
nested INSIDE the wrapper (by indentation, since sibling groups are exactly the
bug), that the title stays a sibling of the wrapper so the row can break between
them, that the wrapper's flex-basis stays auto (with `flex: 1 1 0` it would
measure as zero width, never move down, and the split would come back), that the
h1 can shrink and wrap, and that the export still strips the whole button area.
Thanks to xet7 !
On iPad landscape the board bar wrapped onto two rows: board title, edit,
visibility, watch, star and sort on the first, Filter / Search / view /
dependencies / multi-selection / hamburger on the second.
Measured from the report at a 1180 CSS px viewport, the two rows needed ~613px +
~691px = ~1304px on one line, about 124px more than the viewport. Nearly all of
that is per-button CHROME rather than text: every .board-header-btn carries 12px
side margins (24px), its icon another 10px per side (20px) and a 10px gap after
the label - roughly 54px of empty space around a ~60px icon+label. So nothing has
to be hidden at this width; halving the chrome between 801px and 1400px frees
~295px, which fits the bar on one line at 1180px with room to spare for languages
whose labels are longer than the Finnish ones. Only empty space shrinks - icon
and label sizes are untouched, so the buttons stay comfortable to tap.
Tablet PORTRAIT (iPad 820px) cannot fit ~1009px of icons+labels even halved, so
between 801px and 1000px the labels drop to icons only, the same treatment the
phone block already gives below 801px. Titles, tooltips and popups are unchanged,
so nothing becomes unreachable. Bounded at 1400px so wide desktops, which never
wrapped, look exactly as before; 1400px still covers iPad Pro 12.9" landscape
(1366px), and phones at 800px and below keep their existing 44px touch targets.
Tests: tests/boardHeaderOneLine.test.cjs guards the arithmetic, not just the
presence of the rules - it reads the base and override margins out of header.css
and asserts the halving frees more than the measured 124px deficit (with 2x slack
for longer translations), that button rules in the tablet block change only
margins so the #6419 touch sizing cannot be shrunk back, that the phone block is
untouched, that the overrides come after the base rules they override (a media
query adds no specificity, so source order decides), and that every control on
the bar is a .board-header-btn so the rules actually reach it.
Thanks to xet7 !
On iPad Safari the full-screen "Uncaught runtime errors: ERROR Script error."
panel appeared after login and again when the Safari Share sheet was opened on
All Boards to add WeKan to the home screen.
That panel is webpack-dev-server's error overlay, shipped by the rspack DEV
server (the stack frames are in /__rspack__/client-rspack.js, a path that only
exists when isDevEnvironment; a production build has no dev server and no overlay
at all). Its catchRuntimeError handler opens the overlay for every window 'error'
event, including ones that carry no information: a browser sanitises an error
thrown by a CROSS-ORIGIN script to the bare message "Script error." with a null
error object and no stack, and iOS Safari raises those from its own machinery and
from content blockers / extensions - which is why opening the Share sheet
triggered it.
Such an error cannot come from WeKan's own code: the bundle is served same-origin
(WeKan sets no CDN_URL), so a real WeKan error always reaches the overlay with
its actual message and stack, and WeKan registers no visibilitychange / pagehide
/ blur handlers that the Share sheet could run. There is nothing to act on in
"Script error.", so the overlay now ignores exactly that message and keeps
showing every other runtime error, plus all compile errors, as before.
devServer.client.overlay.runtimeErrors takes an (error) => boolean filter that
webpack-dev-server serialises with toString() and rebuilds in the browser with
new Function(), so the filter is self-contained.
Tests: tests/devOverlayRuntimeErrors.test.cjs round-trips the filter exactly the
way the dev server does (encodeURIComponent(fn.toString()) -> new Function),
checks real errors still open the overlay and malformed input never throws, that
devServer stays out of production/server configs, and - because the base config
puts devServer.client.webSocketURL there on a remote ROOT_URL - that the merge
deep-merges instead of dropping the WebSocket URL.
Thanks to xet7 !
The rows of changeAvatarPopup / adminChangeAvatarPopup rendered the delete link
and the file name INSIDE the a.js-select-avatar anchor. An <a> inside an <a> is
invalid HTML: the browser closes the outer anchor, so the file name and the
"Delete" link fell out of the row's flex layout and rendered as bold text
floating at the right edge, and a click on Delete also selected that avatar.
Delete and the file name were also only rendered for the avatar currently in
use, so no other upload could ever be removed, and an empty p.sub-name added a
stray block in the middle of the row.
Each row is now one flex line: thumbnail, file name (ellipsis-truncated, with the
full name as a tooltip), a green check when it is the avatar in use, and a delete
button that is a SIBLING of the select link - so deleting never also selects, and
every uploaded avatar can be deleted. The row in use is highlighted like the
other pop-over lists, the initials row shows its "Default avatar" sub-label under
the name, and the upload hints (max filesize / allowed filetypes / invalid file)
are grouped into one muted paragraph above the upload button.
Deleting the avatar that is in use left profile.avatarUrl pointing at a file that
no longer existed - a broken image everywhere - which is now much easier to hit
since any avatar can be deleted. Both popups reset the avatar to the initials
when the deleted file is the one in use. The admin popup also passed
userData= to userAvatarInitials, which reads this.userId, so its initials
rendered empty; it now passes userId.
Tests: tests/changeAvatarPopup.test.cjs source-guards the row structure (delete
never nested in the select anchor, never inside `if isSelected`), the reset to
initials and the row CSS.
Thanks to xet7 !
This is the actual cause of the failing "#5592/#5627 copying a board copies its
webhooks and rules" test (all three browsers) — surfaced now that the copy route
returns 500 + logs the stack instead of masking it as 200. The server log shows:
Error: update is not available on the server. Please use updateAsync() instead.
at ensureDefaultSwimlaneId (models/boards.js)
at getDefaultSwimline (models/boards.js)
at Swimlanes.copy (models/swimlanes.js:202)
swimlane.copy() (server, async) called the SYNC getDefaultSwimline() on the source
board to detect its default swimlane. When the board has no pickable swimlane that
getter self-heals via a synchronous Swimlanes.upsert(), which Meteor 3 rejects on
the server, aborting the whole board copy. It now calls the existing
getDefaultSwimlineAsync() (same pick + idempotent upsertAsync self-heal) and awaits
it, preserving the previous null-safety.
The same sync getDefaultSwimline() is still called from other server paths
(models/cards.js, server/models/lists.js, server/rulesHelper.js, swimlanes.js:365);
they only throw when a board has no usable swimlane and are not hit by the current
tests, so they are left for a separate, tested change.
Thanks to xet7 !
Renames rebuild-wekan.sh -> build.sh, rebuild-wekan.bat -> build.bat, and the
guard test tests/rebuildWekanDevServer.test.cjs -> tests/buildDevServer.test.cjs,
and updates every reference across the repo: the docs (Build-from-source, Windows,
Sandstorm, Raspberry Pi, virtual-appliance, Debugging, Developer-Documentation,
FerretDB, OpLog, Rclone, Emoji, Multiverse roadmap, Security remediation, Tests),
README.md, CONTRIBUTING.md, CLAUDE.md, package.json (test:unit:node), the release
scripts (release-all.sh, fix-changelog-hashes.sh, node-update.sh), the disabled
playwright workflow, playwright.config.js, the REST spec comment, tools/forge-mirror.js,
and the CHANGELOG. The menu and every option are unchanged; only the filename and
its references. The website has no references.
Thanks to xet7 !
The last WebKit test run left 8 core dumps in tests/playwright/ — all of WebKit's
WPEWebProcess renderer, one readable dump terminating with SIGTRAP (a deliberate
abort) from the Mesa llvmpipe software-GL stack on this ARM (Apple Silicon / Asahi)
host. A renderer that aborts mid-test makes the next click/navigation time out, so
these surfaced as false WebKit-only failures (05-admin-users, 12-checklists,
20-rules, 39-allboards-sort), not real WeKan bugs.
playwright.config.js now defaults WEBKIT_DISABLE_DMABUF_RENDERER=1 (unless already
set) — the standard fix for WPE WebKit aborting in headless / containerized / VM /
software-GL environments. Playwright passes process.env to the launched browser, so
this covers every run path; it is harmless for Chromium/Firefox, which ignore it.
.gitignore now ignores core dumps (core.<pid>) so a crashing test browser never
leaves untracked multi-MB files that could be committed by accident. The 8 existing
dumps are removed.
Thanks to xet7 !
The Playwright test "#5592/#5627 copying a board copies its webhooks and rules"
regressed (passed 2026-07-23, failed 2026-07-24 in all three browsers): the copy
returned HTTP 200 whose body was an object instead of the new board id string.
Cause of the MASKING: `POST /api/boards/:boardId/copy` did
`catch (error) { sendJsonResult(res, { data: error }) }`, and sendJsonResult
defaults the status to 200 when no `code` is given — so a copy that THREW was
reported as 200 with the error object as the body, looking like a success. The
catch now returns 500 with the message and logs the stack, so a failing copy is
a clean error (and diagnosable in the server log) instead of a wrong 200.
Also hardens board.copy() itself: the custom-field remap did
`card.customFields.map(...)`, which throws for a card whose customFields is
absent (the schema defaults it to [], but a card copied via `.direct` or seeded
raw can lack it), failing the whole copy. It now skips cards with no
customFields, matching the `!Array.isArray(this.customFields)` guard already used
elsewhere in the model.
The copy code and the card/swimlane/list models are unchanged in the regression
window, so the underlying throw comes from an infra change in that window; the
500 + server-side log above make the exact error visible on the next run.
Thanks to xet7 !
Appends item 11 recording that the Per-Swimlane Lists model was reverted to
board-wide shared lists and its migrations removed (#6521), and that data is
still shown without slow migrations via merge-per-swimlane-lists + repairBoardData.
Thanks to xet7 !
The per-swimlane-lists model was reverted (its migrations were removed in #6521);
lists are board-wide and the same lists appear in every swimlane. Update the docs
to say so:
* Features/Lists/Lists.md and Features/Board/Swimlanes.md now state plainly that
lists are shared across swimlanes (a card belongs to one list and one
swimlane), and that per-swimlane lists were an experiment that was reverted.
* The docs/Databases/Migrations/ writeups (MIGRATION_SYSTEM_IMPROVEMENTS,
MIGRATION_SYSTEM_REVIEW_COMPLETE, CODE_CHANGES_SUMMARY, SESSION_SUMMARY,
verify-migrations.sh) describe the old cron-driven migration system and the
per-swimlane-lists migration, both removed; each now carries an OBSOLETE banner
pointing at the current board-wide model and the live repair paths
(merge-per-swimlane-lists + repairBoardData).
The dated PerUserDataAudit2025-12-23 snapshot is left as-is: it already observed
that lists are board-wide, and it is a point-in-time record.
Thanks to xet7 !
New Setup menu action in both rebuild-wekan.sh and rebuild-wekan.bat that makes
the working copy current in one step: git fetch --all --prune, git pull --rebase
--autostash onto origin/<branch>, then repoint any CHANGELOG commit links the
rebase made stale, then show git status. It never commits; if the hash fix
changed CHANGELOG.md it says so and leaves it for review.
The commit-link repair that used to live inline in releases/release-all.sh is
extracted to releases/fix-changelog-hashes.sh so there is ONE implementation,
called by both release-all.sh (before a release) and the new Update-git option.
Behaviour is unchanged: only the unreleased section is touched, stale links are
repointed to the same-subject rewritten commit, unresolved links warn and never
abort, and it always exits 0.
The Windows .bat calls the shared bash script via Git Bash (bundled with Git for
Windows) and degrades gracefully with instructions when bash is not on PATH.
changelogCommitLinks.test.cjs now guards the shared script plus the fact that
both callers reuse it and release-all.sh keeps no duplicate copy.
Thanks to xet7 !
The v10.34 version bump rebased the post-release work, so the header follow-up
and the #6521 migration-removal bullets linked hashes that no longer exist on the
branch (33ca42a32 -> e28181734, 88a076561 -> 52d68be75). Matched by commit
subject and repointed. Only the not-yet-released Upcoming section is touched.
Thanks to xet7 !
The v10.34 release commit renamed the Upcoming section to v10.34 while the header
follow-up (display:contents) and the #6521 migration removal were committed just
after it. Their CHANGELOG entries had landed inside the now-released v10.34
section (and had rewritten v10.34's mobile-header bullet). Restore v10.34 to what
it shipped and put both post-release bug fixes under a new "Upcoming WeKan ®
release" section instead.
Thanks to xet7 !
#6521: after upgrading toward 10.33 a board grew a new "Restored Items" column
full of cards that looked empty but were not. That column, and the card moves
behind it, came from obsolete board migrations that fight the CURRENT data model:
* restoreLostCards - created a "Lost Cards" swimlane and a "Restored Items" list
(i18n lost-cards / lost-cards-list) and moved cards into them. It called a card
"orphaned" when its list was merely ARCHIVED (archived lists are excluded from
the set it checks) and "lost" when its swimlaneId was '' - which is NORMAL for a
board-wide shared card - so it dragged real, fine cards into "Restored Items".
* comprehensiveBoardMigration / fixMissingListsMigration - converted today's
board-wide SHARED lists (swimlaneId '') back into per-swimlane DUPLICATE
columns, i.e. the exact damage the startup schema step merge-per-swimlane-lists
now UNDOES.
* restoreAllArchived - un-archived every swimlane/list/card at once.
All four had NO callers left - their admin migration dashboard was already
removed - so they were dead code exposed only as admin-callable Meteor methods, a
footgun that could re-corrupt a board if invoked. They are removed, along with
their imports and the stale commented-out imports in 00checkStartup.js.
The legitimate paths remain and are correct: the board-open self-heal
(repairBoardData) assigns a genuinely missing swimlaneId / relinks orphaned cards
to the board's real first list/swimlane, and the startup schema step
merge-per-swimlane-lists merges any per-swimlane duplicate columns back into one
shared list while cards keep their swimlaneId. It still keys off the era's board
markers (fixMissingListsCompleted / comprehensiveMigrationCompleted) in existing
data, so removing the code that once wrote them changes nothing for already-migrated
boards.
Adds tests/obsoleteBoardMigrationsRemoved.test.cjs so these cannot come back.
Thanks to hmeunier95 and xet7 !
Fixes#6521,
Two follow-ups to the phone All Boards header.
The section icon still sat alone on row 1 with the Multi-Selection / Sort
buttons stranded on row 2. Those buttons and the search box are wrapped in a
`.path-right` element, so giving that wrapper `flex` only made IT wrap as a
two-line block below the icon. On a phone `.path-right` is now `display:
contents`, which dissolves the wrapper so its buttons and search field become
direct items of the header's flex row; the header then wraps them itself - the
section icon and buttons on row 1, the full-width search box on row 2.
The workspace NAME on the narrow left menu could spill over the "bars" workspace
menu button to its right, so the hamburger looked like it was drawn on top of the
name. The earlier min-width floor on the name caused it: in the narrow menu it
stopped the name shrinking, so its box overflowed onto the menu. The floor is
removed and the name's box (js-select-space) is clipped, so the name truncates
with an ellipsis and can never cover the menu; the menu button and count never
shrink.
Thanks to xet7 !
#6520: the Problems "Status" page showed "Board data-repair — 146/146 boards"
running forever (plus a matching "Migration or repair" login warning), and the
CPU area showed dozens of "new problems" on an idle server.
Board repair stuck at "running": getInProgress() trusted the raw `running` flag.
The startup repair DOES write running:false on completion, but its progress
callback also fired a NON-awaited running:true write when boardsDone ===
boardsTotal; being fire-and-forget, that write could land AFTER the awaited
completion write and pin the doc at "running, 146/146". A process killed
mid-repair leaves running:true too. Both now clear:
* the startup progress callback no longer writes the terminal boardsDone ===
boardsTotal update (the completion write owns the final state), closing the
race at the source;
* getInProgress() now asks the new pure isStatusActive() instead of reading
`running` directly - a doc is "in progress" only while running AND not in a
terminal phase (completed/error/done) AND not already finished by count
(done >= total) AND updated recently (a running flag with no recent progress
write is a crashed run). This also heals docs already stuck on an instance,
and fixes the same class of stale flag for the text migration. Because the
login "Migration or repair" warning keys off getInProgress(), it clears too.
CPU "57 new problems" on an idle server: the count in eventLogProblemAreas
counted every unacknowledged row in a stream. The CPU monitor writes one
'detected' row when a high-CPU period starts and several severity:'info' rows
('remediated' when it ends, 'rate-limited' for mitigation, FerretDB governor
chatter), so each brief, already-over spike looked like several "new problems".
The count now excludes severity:'info' rows (via the new newProblemsSelector) -
notices that a problem was handled or cleared are not problems. Rows with no
severity are still counted, so nothing unclassified is silently dropped.
Both decisions are pure, unit- and negative-tested (statusActive.test.cjs,
eventLogProblems.test.cjs), and registered in test:unit:node.
Thanks to Alishara and xet7 !
Fixes#6520,
`tx push -s` failed with `parse_error: Duplicate string key` because
en.i18n.json had two `cpu-cores` keys: the existing "CPU Cores" (already on
Transifex with human translations) and a second "cores" added by the CPU-usage
feature. A JS JSON parser silently keeps the last, so the app never noticed, but
Transifex rejects duplicates - and the collision also meant `cpu-cores` resolved
to "cores" everywhere.
The feature's string needs a different value ("N cores"), so it moves to a new
unique key `cpu-cores-suffix`; the pre-existing `cpu-cores` "CPU Cores" is left
untouched, matching every other language file, so no human translation is
disturbed. Only the one template that used it (Admin Panel / Problems / CPU
usage) is repointed.
Thanks to xet7 !
This developer-tooling change (registering five never-run mocha suites, two of
them *bleed security regression suites, plus the testsAreRegistered guard, and
deleting responsiveFixes.css and the empty backgrounds tombstones) was committed
after v10.33 but had no CHANGELOG entry. Every other post-v10.33 commit is
already covered, individually or as a consolidated fix series.
Thanks to xet7 !
On a phone the All Boards path header put the section icon alone on a wasted
first line while the Multi-Selection and Sort buttons sat on the next line. The
section icon and those buttons now share ONE row (path-left becomes flex 0 0
auto and stays on the buttons' row), and the Search box takes a full-width row
of its own beneath them (flex-basis 100% forces the wrap).
The blue Sort button showed as an empty blue square: its icon was the wrapped
`fa-sort-alpha-asc`. It now uses the plain `fa-sort` glyph as a direct `i.fa`
child, matching the Multi-Selection button beside it whose icon renders, so the
button always shows a sort icon.
On the narrow left menu each workspace name now keeps a small floor of width
(min-width, with the trailing menu button and count shrinking first) so at least
the first few characters stay visible and a workspace can be told apart while it
is dragged. An unnamed workspace still shows just its icon.
Thanks to xet7 !
HTML5 drag-and-drop never fires from touch, so the board-icon reorder (and the
other HTML5-DnD spots) only worked with a mouse. This adds
client/lib/dragDropTouch.js: a long press on a `draggable="true"` element starts
a synthetic drag that dispatches REAL, bubbling
dragstart/dragenter/dragover/dragleave/drop/dragend DOM events with a
dataTransfer shim - so every existing delegated handler works from a finger with
no change to the reorder logic, the workspace drag-to-share, or the card/rule
drags.
Chosen to be safe alongside the existing touch scrolling:
* LONG PRESS (250 ms) to start - a quick swipe on a draggable tile still
scrolls; only a deliberate hold-then-move begins a drag, and preventDefault
is called ONLY once a drag is under way.
* It fires a `mousedown` on the pressed element first, so the board reorder's
handle gate (which records the mousedown target) works from touch too.
* setDragImage is honoured, so the ghost is centred on the finger exactly as it
is on the cursor for a mouse.
* It excludes form fields and jQuery-UI sortables (lists/swimlanes/cards
already get touch via touch-punch), and coexists with dragscrollTouch.js,
which already skips the `.nodragscroll` board tiles and handle.
Loaded globally (via pageDragscroll / boardBody, and imported in boardsList).
Adds tests/dragDropTouch.test.cjs pinning the properties above.
This is Option A from the discussion - it keeps every mouse fix and every other
HTML5-DnD feature, rather than rewriting reorder onto jQuery-UI-sortable.
Thanks to xet7 !
You had to drag a board icon to the LEFT edge of the target for the gap to open
there. The reason: HTML5 dragover fires for whatever is under the CURSOR, but an
icon is grabbed off-centre (often at the move handle on the right), so the ghost
sat beside the cursor - when the ghost looked like it was over the target, the
cursor was actually over the neighbour, and the gap opened for the wrong icon.
The drag image is now centred on the cursor (setDragImage at the icon's centre),
so "ghost over the target" and "cursor over the target" line up. Combined with the
whole-icon insert-before from before, dropping the ghost onto a target icon now
opens the gap at that icon regardless of where on it you grabbed the dragged one.
Thanks to xet7 !
The dragged board icon stayed put in its slot during the drag, so the grid had
one extra tile and the live gap appeared one slot to the LEFT of where the board
would actually land - dropping "Eikun" onto "juuppa" showed the gap beside juuppa
instead of at it.
The dragged icon is now taken OUT of the grid flow while dragging
(`display: none`, added on a timeout after dragstart so the drag image is already
captured, removed on dragend). The other icons reflow as if it were gone, so the
gap sits exactly where the icon will land and "juuppa" moves aside to show the
drop slot.
The order computation already skips the dragged id, and the "is this the last
tile?" check now ignores the hidden (still-in-DOM) dragged tile, so reordering the
last board still works.
Thanks to xet7 !
The live gap used a left/right-half threshold on every board icon: the left half
inserted before, the right half after. So to land a board in a given slot you had
to aim the LEFT half of the icon occupying it, which was fiddly.
Now hovering anywhere on a board icon opens the gap AT that icon's slot (insert
before it), so dropping a board onto an icon puts it in that icon's place - drop
where it should stay, no half-aiming. The only exception is the LAST icon, whose
trailing half still inserts after it, so the end of the order remains reachable.
Thanks to xet7 !
The section icon left of the Multi-Selection button was a Unicode emoji
(⭐📋📂🗂️), which does not match the left menu, where Starred / Templates /
Remaining / Workspaces use Font Awesome glyphs (fa-star, fa-clipboard, fa-folder,
fa-folder-open). currentMenuPath now also returns a `faIcon` for the current
section, the header renders `i.fa` with it, and it is coloured #4d4d4d and sized
like the menu icons - so the header icon is the same glyph and colour as the
matching left-menu item.
Thanks to xet7 !
Reordering a board within a workspace (or any view) put it back where it started.
The `drop .js-board` handler only fires when the pointer is released over a BOARD
tile - but the gap the user aims at is the placeholder `<li>`, which is NOT a
`.js-board`, so releasing over it hit no drop handler and the optimistic move
reverted.
The drop now reads the intended order straight from the DOM using the gap's real
position (every board id in list order, with the dragged id taken from its old
slot and put where the placeholder sits), and there are `dragover`/`drop`
handlers on `.js-board-placeholder` so releasing over the gap itself works. Both
the tile-drop and gap-drop paths share one persist function, and it no-ops when
the visible order did not change.
This removes the earlier before/after target math (computeReorderedSortIndex) in
favour of the DOM position, which is exactly what the user sees, so the persisted
order always matches the gap.
The write itself was already permitted - the users allow rule accepts
`profile.*` and the schema field was added in the previous commit - so with the
drop actually firing, the reorder persists.
Thanks to xet7 !
Replaces the fixed "drop at the end" placeholder with the standard sortable feel:
while a board is dragged, an empty dashed gap opens up before or after the tile
under the cursor, showing exactly where the board will land - anywhere in the
current view (Starred / Templates / Remaining / a workspace), not only at the
end.
How it works:
* `dragover .js-board` computes which side of the tile the cursor is on
(inline-centre, RTL-aware) and inserts a placeholder `<li>` there. The
placeholder is a plain DOM node, inserted next to the Blaze-managed tiles and
removed on dragend, so it never fights Blaze's reactive list.
* `drop .js-board` reads that side and reorders with the pure
computeReorderedIds(..., after), which now inserts on the target's leading OR
trailing side and returns null for a no-op (including a drop back into the
board's own slot). Dropping past the last tile reaches the end, so the
separate end target is gone.
The placeholder is a real grid cell, so the surrounding tiles flow around the gap
as it moves. Unit tests cover the new before/after side and the own-slot no-ops.
Still mouse-only: HTML5 drag-and-drop does not fire from touch (the jQuery-UI-
sortable + touch-punch move noted before is what would add finger dragging).
Thanks to xet7 !
The header showed the current folder's icon AND its name ("Starred", "Remaining",
a workspace name) just left of the Multi-Selection / Sort / search controls. The
name was redundant - the folder icon already indicates the section, the left menu
highlights it, and the "My Boards" bar names the page - and it crowded (and on
narrow widths overlapped) those controls.
The `.path-text` is now visually hidden rather than removed, so a screen reader
still announces which folder is shown; the icon alone has no text alternative.
Thanks to xet7 !
Dropping one board onto another can only place it BEFORE that board, so the last
slot in the order was unreachable by drag. A dashed "drop here to move to the
end" tile now sits after the last board (only in the manual "custom" sort mode,
where drag-reorder applies) and accepts a drop that moves the dragged board to
the end.
The move-to-end order math is the pure computeReorderedSortIndexToEnd in
models/lib/boardSortReorder.js (a no-op when the board is already last); the
dragover/drop handlers mirror the board-tile ones and light the placeholder with
the same `.board-reorder-over` highlight.
Thanks to xet7 !
Dropping one board onto another to reorder threw INVALID [400]. setBoardSortIndexes
writes `profile.boardSortIndex` from the client via Users.updateAsync, and the
user `profile` object ENUMERATES its subfields in the schema (it is not blackbox)
- but `profile.boardSortIndex` had no schema entry, so SimpleSchema rejected the
update with a 400.
Added the entry next to the analogous `profile.autoWidthBoards` /
`profile.fixedListWidthBoards` (type Object, defaultValue {}, blackbox, optional).
The #6439 drag-reorder now persists instead of erroring.
Thanks to xet7 !
A finger tap on "+ Add workspace" often did nothing while the larger menu rows
(Starred, Remaining, a workspace name, the workspace menu button) worked fine. It
was a ~20px "+" link with `padding: 2px 8px` - well below the 44px minimum touch
target, so a finger usually landed just outside it. On a touch-capable layout it
is now a 44x44 target with the "+" centred. The click handler (opens the
add-workspace popup) is unchanged.
Thanks to xet7 !
With drag handles ON, dragging the handle did nothing (mouse or finger). The gate
that restricts the drag to the handle checked
`dragstart.target.closest('.board-handle')` - but in Chrome and Firefox the
dragstart event's `target` is the DRAGGABLE element itself (the whole
`li.js-board`), not the sub-element the pointer was on. So the closest() was
always null, the gate treated every handle drag as "not on the handle", and
cancelled it.
The press location is now recorded on `mousedown .js-board` (which does fire on
the handle), and dragstart reads that flag instead. The flag is reset on dragend
so a later drag that starts elsewhere is not wrongly allowed. Mouse drag from the
handle now reorders; a drag that starts on the rest of the tile is still
cancelled so that area stays free.
Touch is unchanged and still does not reorder: HTML5 drag-and-drop does not fire
from touch at all, which needs the separate jQuery-UI-sortable + touch-punch move
noted before.
Thanks to xet7 !
Dragging a board tile to reorder used the tile's HTML5 drag (draggable="true" +
the dragstart/dragover/drop handlers). Two things on the same tile were stealing
the mouse drag before that native drag could start:
* the board list <ul> is a `.dragscroll` element, so the mouse dragscroll
library pans it on mouse-drag - and the tiles were not `.nodragscroll`, so
grabbing a tile panned the list instead of starting the board drag;
* `a.js-open-board` is a link, and a link is draggable by default, so grabbing
the board title dragged the URL rather than the board.
`li.js-board` is now `.nodragscroll` (dragscroll leaves the tile alone) and the
inner link is `draggable="false"` (the tile's own drag starts instead; the link
still navigates on click). Star/unstar and "+ Add Board" are clicks, so they are
unaffected. Vertical scrolling of the list still works natively.
KNOWN, NOT fixed here: reordering by FINGER on a touchscreen. Board reorder uses
HTML5 drag-and-drop, which browsers do not fire from touch at all - so touch
needs a polyfill or a move to jQuery-UI-sortable + the touch-punch this app
already bundles (what lists/swimlanes use). That is a larger change and is called
out separately rather than half-done here.
Thanks to xet7 !
The board list had two FIXED-column layouts, and both stretched the tiles wider
as the window grew instead of fitting more per row:
* desktop: `float; width: 20%` - a fixed 5 columns (4 after margins);
* mobile-view: `grid-template-columns: repeat(2, minmax(0, 1fr))` - always 2.
That is why widening the window alternated "nice square tiles" and "few very
wide tiles" instead of steadily adding columns.
Both are now `repeat(auto-fill, minmax(..., 1fr))`, which fills each row with as
many tiles of a steady size as fit, so more width = more boards per row:
* desktop `minmax(200px, 1fr)` - ~3 columns at 1000px up to ~11 at 2500px;
* mobile-view `minmax(min(46%, 200px), 1fr)` - the `min(46%, ...)` keeps ~2
columns on a narrow phone board-column while a wider one (a laptop in mobile
mode) gets more, capped at a 200px tile.
The 8px grid `gap` replaces the per-tile 8px margins (now 0), and the float on
the list items is reset since grid places them.
Phones are unaffected: the `max-width: 800px` / device-iPhone media queries still
pin `repeat(2)` there, and on a phone `.board-list.mobile-view` (higher
specificity) resolves to 2 columns anyway.
Thanks to xet7 !
The zoom %, notification bell and user/avatar menu are the last items in the
quick-access bar. When the starred-boards list in the middle is shown it fills
the gap with `flex: 1` and pushes them to the end - but that list is
`display: none` on a phone, so with nothing filling the middle the group bunched
at the START (left in LTR) with empty bar to its right.
`margin-inline-start: auto` on the first item of the group (the zoom control)
pushes the whole group to the end. Being a LOGICAL margin it is the right edge in
LTR and the left edge in RTL automatically, which is the requested behaviour. An
auto margin an earlier small-width rule had put on the user bar is cleared, so
there is exactly ONE auto in the row - two would split the free space and
separate the group. The rule is last in the file, so it wins on source order.
Thanks to xet7 !
At wider (laptop) widths the board tiles merged - "Just" and "juuppa" ran
together into one blue block with no gap, and the tiles lost their proper width.
The equal-height/equal-width work done earlier for the phone had six rule groups
whose selector lists included a BARE `.board-list ...` variant alongside the
intended `.board-list.mobile-view ...` one, so they also applied on desktop where
`.mobile-view` is absent. Two of them broke the desktop float layout:
.board-list li.js-board { margin: 0 !important } /* killed the 8px gap */
.board-list li { padding-inline-end: 0 } /* and other geometry */
removing the spacing that `.board-list li { width: 20%; margin: 8px }` relies on,
so adjacent coloured tiles touched and read as one block.
All six groups are now `.board-list.mobile-view` only, so the desktop float
layout (untouched `width: 20%`, `margin: 8px`) is restored and the phone layout
is unchanged. Verified that no non-media, non-mobile-view rule sets
`margin: 0 !important`, `width: auto` or `height: 4rem` on a board tile.
Thanks to xet7 !
iPhone landscape is ~844px CSS-wide - above the 800px breakpoint but still an
iPhone, so the device-width media query (`max-device-width: 932px and
-webkit-min-device-pixel-ratio: 3`) applies while the plain `max-width: 800px`
rules do not. That split caused all three symptoms:
1. The left menu was `minmax(140px, 42%)`. 42% of 375px is 158px (fine in
portrait), but 42% of 844px is ~354px - a very wide column, and because each
menu item is `justify-content: space-between` with a `flex: 1` label, the
count chip was flung to the far edge, ~250px from its label. The column is now
`minmax(140px, min(42%, 210px))`: portrait is unchanged (158px is below the
cap), landscape is capped at 210px.
2 + 3. The count now sits right after its label (mobile only: `justify-content:
flex-start`, non-growing label, `gap`), so there is no large empty band even
at 210px, and the desktop 260px menu is left alone.
4. The folder header ("Remaining" + multi-selection buttons + search) stacked
onto rows only at `max-width: 800px`, so at 844px it stayed a single row and
the buttons overlapped the "Remaining" title. Its stacking media query now
carries the same device-width branch as the grid layout, so it stacks in
landscape too.
Thanks to xet7 !
Dragging the header bars scrolled the page but dragging the grey content area did
not. The header sits OUTSIDE #content, so the fact that it scrolls proves the
BODY is the real scroller. The previous commit had made #content its own
`overflow-y: auto` scroller - and in the content area that TRAPPED the touch:
#content caught the gesture and, having nothing of its own to scroll, did not
pass it on to the body, so a finger over the text did nothing while the same drag
over the header still worked.
#content is a pass-through again: `overflow: visible` so it does not catch the
touch, and `flex: 0 0 auto; min-height: auto` so it takes its content's full
natural height instead of being squeezed to the viewport by the default
`flex: 1`. The body's content is then taller than the body, so the body scrolls -
one scroller, reachable by a finger anywhere.
The body keeps `100dvh` (bottom tracks Safari's toolbar, not the large `100vh`),
`overflow-y: auto`, and `overscroll-behavior: contain` (no pull-to-refresh). Still
scoped with `body:has(.wrapper.global-search-wrapper)`, so only this page changes.
Thanks to xet7 !
Every earlier attempt treated the wrapper; the bottom stayed unreachable in both
orientations because of #content, not the wrapper.
#content is a flex child of the body flex-column, and a flex child defaults to
`min-height: auto` - it refuses to shrink below its content, so it grows to fit
and NEVER scrolls. Content past the fold just overflowed out of reach. `min-height:
0` is what lets it become a real scroller. That was the missing piece the whole
time.
The other half was the iOS toolbar: `body`/#content were `100vh`, which on iOS is
the LARGE viewport (toolbars hidden), so the scroller's bottom sat behind the
toolbar. `100dvh` - the dynamic viewport, which shrinks when the toolbar shows -
keeps the last line above it, in both portrait and landscape.
So on this page #content is the single scroller: `min-height: 0; overflow-y:
auto`, inside a `100dvh` body, with `overscroll-behavior: contain` to stop the
drag chaining out to the document (which fired pull-to-refresh in landscape). The
wrapper goes back to plain content so its full height feeds #content's scroll
range.
All of it is behind `body:has(.wrapper.global-search-wrapper)`, so it applies
only when the search page is shown and no other page's #content is changed. :has,
dvh and overscroll-behavior are all supported on the iOS Safari and Firefox
versions in question.
Thanks to xet7 !
Scrolling reaches the end now, but the last line still sat under Safari's bottom
toolbar. The page's scroller `#content` is sized `calc(100vh - 48px)`, and on iOS
`100vh` is the LARGE viewport (toolbar hidden), so the scroller's bottom edge is
behind the toolbar when it is shown - the final bullet ("By default archived
cards are not searched.") ends up under it with nothing able to scroll it clear.
The wrapper's bottom padding is raised from 24px to
`calc(120px + env(safe-area-inset-bottom, 0px))`. That empty scrollable space
after the content lets the last real line scroll up above the toolbar; the
safe-area inset covers the home indicator, and the fixed 120px covers the toolbar
itself, which the inset does not include. Empty trailing space is harmless - it
only extends the scroll range.
Thanks to xet7 !
The last fix un-clipped the page by making its wrapper its OWN scroll box
(`min-height: 100vh; overflow-y: auto`). That box is taller than its parent
`#content`, which is itself a scroller in mobile mode - so BOTH scrolled. On iOS
Safari, reaching the bottom of the inner box handed the scroll off to `#content`
and then rubber-banded back to "Differing operators", which is the reported jump.
Fairphone Firefox does not rubber-band, so it just reached the end - the same two
scrollers, only one of them visibly misbehaves.
The clip is now released WITHOUT adding a second scroller: `.wrapper` for this
page is `height: auto; overflow: visible`, so it grows to its real content height
and neither clips nor scrolls. `#content` (the page's existing scroller, and what
a finger scrolls natively on touch) is then the single scroller, and a single
scroller cannot fight itself - no jump, and the last line
("By default archived cards are not searched.") is reachable on both phones.
The override is `.wrapper.global-search-wrapper` (0,2,0), which beats the
boardsList `.wrapper` clip (0,1,0) regardless of stylesheet order.
The `.dragscroll` class is dropped from the wrapper: with `#content` scrolling
natively there is nothing for dragscrollTouch.js to do, and native touch
scrolling already works on a normal vertical page.
Thanks to xet7 !
The previous commit gave each panel its own `max-height: calc(100vh - 120px)`
scroll box. That did not work: the panels start BELOW the search form, so their
bottoms - and their scrollbars - ended up past the bottom of the wrapper, which
is clipped at `height: 100vh; overflow: hidden`. The result was text cut off
mid-character after "Notes" on iPhone, and the list ending at "Differing
operators ... red label." on Fairphone 4, with no way to scroll to the rest.
The page now has exactly ONE scroll container instead of nested ones. This page's
wrapper is tagged `global-search-wrapper` and, at phone widths, is
`height: auto; min-height: 100vh; overflow-y: auto` - at least a screen tall and
growing with its content - while the panels inside go back to plain content with
no height of their own. Nothing can be clipped between two scrollers because
there is only one, and 24px of bottom padding keeps the last line clear of the
browser's bottom bar.
`.dragscroll` moved to that wrapper and was REMOVED from the panels, which is
required rather than tidying: dragscrollTouch.js takes the NEAREST `.dragscroll`
ancestor and gives up if that one cannot scroll - it does not keep walking up. A
`.dragscroll` class left on a panel that no longer scrolls would therefore have
disabled finger dragging on the whole page.
Thanks to xet7 !
Three problems, one root cause each.
1. Label Colors ran off the right edge into the invisible area. The palette
already has `flex-wrap: wrap`; it could not help, because its container
`.global-search-page` is `width: 40%; min-width: 400px` - sized for a desktop
column - so on a 375px phone the block itself was already wider than the
screen and there was nothing to wrap into. At small width the page block is
simply as wide as the screen, and the wrappers with their own desktop minimums
are released too so they cannot re-create the overflow one level down.
2. The page could not be scrolled down AT ALL. `.wrapper` - the GLOBAL layout
element - is given `height: 100vh; overflow: hidden` by the All Boards
stylesheet at this width. That is fine for the boards page, which provides its
own scroll container, but it applies to every page, and this one had none, so
everything below the fold was unreachable. The help panel and the results list
now have a bounded height with `overflow-y: auto`.
(The deeper issue is that a page-specific `.wrapper` rule lives in
boardsList.css and affects every page at this width. Fixing that properly means
scoping it to the boards page; this commit does not, because every other page
currently depends on the behaviour one way or another.)
3. Dragscroll did not work with a finger. client/lib/dragscrollTouch.js scrolls
the nearest `.dragscroll` ancestor that can actually scroll - and no element on
this page had the class. The help panel and the results list now carry it, and
with (2) they are scrollable, so both conditions the handler needs are met.
The query form shares the `.global-search-page` class but is a short fixed
header, so it is explicitly excluded from becoming a scroll box of its own.
Thanks to xet7 !
Admin Panel / Version needed a horizontal scroll to read a value that easily fits
on screen: "WeKan Version" sat at the left edge and its version number about a
thousand pixels away.
The cause is deliberate, and applies to EVERY admin table:
.setting-content .content-body .main-body table { min-width: 1200px !important }
.setting-content .content-body .main-body table td { white-space: nowrap }
with the comment "Force tables to always trigger horizontal scrolling". That is
reasonable for the wide data tables, but a two-column table like Version is
pushed to 1200px for no reason, and nowrap cells can never use a second line.
At small width the table is now allowed to be as wide as the screen and no wider,
and cells may use as many lines as they need; long unbroken values (version
strings, paths, URLs) break instead of pushing the table wide again. The label
column keeps a 45% share so it does not collapse to one character per line beside
a long value. Horizontal scrolling still works where a table genuinely cannot
fit - it is simply no longer forced on tables that would fit comfortably.
The override is last in the file and repeats the same selectors, so it wins on
source order at equal specificity.
Thanks to xet7 !
Clicking "+" beside Workspaces called window.prompt(). A browser is free to
refuse that: iOS Safari offers "don't allow further prompts" for a page and then
suppresses every later one, so the button did nothing at all and no input field
ever appeared - which is exactly what was reported.
It now opens a normal WeKan popup with a text input and a submit button, the same
pattern every other create flow here uses (workspaceActionsPopup already has an
identical "add subworkspace" form). Submitting with an empty field keeps the
popup open and refocuses the input rather than closing silently, which is what a
cancelled prompt() used to look like.
Adds the addWorkspacePopup-title i18n key; the field label and button reuse the
existing allboards.add-workspace-prompt / allboards.add-workspace strings.
This was the only window.prompt() left in the client.
Thanks to xet7 !
The setting governed swimlanes, lists and cards on a board, but board TILES on
All Boards always showed their drag handle and were always draggable from
anywhere, so turning handles off did nothing there.
The handle markup is now behind the same helper as everywhere else, in both
places it appears (a normal board tile and a template-container tile).
The drag source follows it as well, which is the half that matters: with handles
ON the handle is the ONLY place a board drag may start, so the rest of the tile
stays free and a finger dragging across it scrolls the board list instead of
picking the board up - the same contract cards and lists follow. With handles OFF
there is no handle to grab, so the whole tile drags, exactly as before.
Boards use HTML5 drag-and-drop rather than jQuery sortable (the sortable code is
commented out in this file), so this could not be done by swapping a `handle`
option. The `li` keeps `draggable="true"` either way - a drag can only start from
a draggable element, and moving the attribute onto the handle would drag the
handle rather than the board - and `dragstart` instead cancels the drag unless it
began inside `.board-handle`.
With no handle rendered, the tile's title also reclaims the 28px that was
reserved for it.
Thanks to xet7 !
Forcing "Remaining" and the search onto one row was the wrong half of the fix: on
a 375px phone the title was ellipsised down to "R.." and the search box still had
barely any width, while a wide screen has room for both side by side.
They stack again - title first, search under it - but without what made stacking
look wrong before. The old two-row layout separated them with a tall empty band
because `.path-right` was free to grow; now each part takes exactly one
full-width row (`flex: 1 1 100%`) with a fixed 6px `row-gap`, so the search sits
directly under the title. The search still needs `min-width: 0` to share its row
with the multi-selection buttons: a flex item defaults to `min-width: auto` and
otherwise refuses to shrink below its content width.
Thanks to xet7 !
Two things made them differ, in opposite directions.
Width: the previous commit had "+ Add Board" span both grid columns, which was
the earlier request but not this one - identical tiles is what a wide screen does
and what was asked for. It is one cell again, like any board tile.
Margin: `.js-add-board` carries `margin: 8px !important` and `.js-board` carries
`margin: 8px`, both outside any media query. Zeroing only the add tile - which is
what the first attempt at this did - would have made IT the odd one out instead.
Both are now `margin: 0` at small width: the grid already puts an 8px gap between
cells, so a margin on top of that only shrinks the tiles, and unevenly if the two
do not match exactly.
Height was already 4rem for both; that is now also pinned on the tile INSIDE each
li (`width: 100%; height: 4rem`) so nothing within can change it, and the li
itself is left to the grid (`width: auto; min-width: 0; max-width: none`).
Result at 375px: every tile is one 96px x 64px cell, add and board alike.
Thanks to xet7 !
Four fixes, all so the small-width layout matches what a wide screen already
does.
1. Board titles broke ONE LETTER PER LINE. The drag handle is a single ~26px
absolutely-positioned circle, but space for it was reserved THREE times on the
way down: 32px on `li`, 30px in the tile's padding, and 30px again on
`.details`. On a ~96px tile that is 92px of reservation, leaving about nothing
- so every character wrapped. An absolutely-positioned handle only needs the
innermost text container to keep clear of it, so it is reserved once, on
`.details`, leaving ~52px of text: the title reads left to right again.
2. "+ Add Board" now spans both grid columns, so it is twice the width of a board
tile and reads as an action rather than as another board.
3. The header wrapped onto two rows on a phone - "Remaining" on one, the search
box on another, with a tall empty band between - while a wide screen puts them
side by side. The search box would not shrink, because a flex item's default
`min-width: auto` refuses to go below its content width; `min-width: 0` plus
`flex: 1 1 auto` lets it take what is left beside the title, and the row no
longer wraps.
4. The "Search boards" placeholder is removed. The magnifier beside the field
already says what it is, and the label filled the whole box on a phone. An
`aria-label` replaces it, which is what a placeholder should never have been
standing in for.
Thanks to xet7 !
Board tiles still towered over "+ Add Board" after both were set to 4rem, for a
reason that had nothing to do with either tile's height: the mobile board list is
a GRID with a fixed height (`height: calc(100vh - 120px)`) and no
`align-content`, so it defaulted to `stretch` and its single row was stretched to
fill the whole column. "+ Add Board" showed a 4rem grey `.label` sitting at the
top of a stretched cell, while a board's `li.js-board` carries the board colour
itself and therefore painted the entire stretched cell blue - so one looked short
and the other several times taller.
`align-content: start` keeps rows at their content height instead of dividing the
leftover space among them, and `align-items: start` / `align-self: start` stop
each tile stretching to its row. The list still scrolls: the fixed height plus
`overflow-y: auto` is what makes it a scroll container, and that is untouched.
Also rebalances the two columns on mobile, in both places that declare them: the
left menu goes from `minmax(84px, 30%)` to `minmax(140px, 42%)`. At 30% of a
375px phone the menu was ~112px, so "Workspaces" and the counts wrapped and it
read as cramped, while the board column had more width than two 4rem tiles need.
42% gives ~158px of menu and ~209px of boards, which still fits two tiles of
~97px side by side.
Thanks to xet7 !
The previous commit set both to 4rem, but only the add tile actually shrank: a
board tile stayed 8rem, so on the Remaining tab one board icon towered over
"+ Add Board" instead of matching it.
Two selectors decide that height and they are not equally specific:
.board-list.mobile-view .board-list-item (0,3,0) height: 8rem
.board-list .board-list-item (0,2,0) height: 4rem <- lost
`.mobile-view` is put on the <ul> by the template from Utils.isMiniScreen(), so
it is present on a phone; the add tile escaped only because it is matched by
`.board-list .js-add-board .label`, which is also (0,3,0) and came later in the
file. Hence one tile shrank and the other did not.
Both `.mobile-view` shapes are now spelled out, so the rule ties on specificity
and wins on order.
The 8rem rule is also OUTSIDE any media query, while the 4rem rule was inside
`@media (max-width: 800px)`. Utils.isMiniScreen() weighs mobile MODE and the
device as well as width, so `.mobile-view` can be set on a wide screen, where the
media query does not apply and the mismatch would have come straight back. The
override is therefore repeated at the end of the file, outside any media query,
matching how the rule it overrides is written.
Thanks to xet7 !
On a phone a board tile was 8rem (128px) while the grey "+ Add Board" /
"+ Add Template Container" tile had no mobile height at all: it fell back to the
desktop `min-height: 72px` plus 42px of padding and then grew further around its
wrapped label. So the two were never the same height, and both wasted vertical
space on a screen that has little of it.
Both are now a flat 4rem (64px) with `box-sizing: border-box`, so the number IS
the rendered height rather than a floor that padding is then added to. The board
tile's 24px/18px vertical padding is cut to 6px, which is what made it tall; the
add tile centres its label with flex, so it only needs enough padding not to
touch the edges.
One rule covers every tab of All Boards - Starred, Templates, Remaining and
Workspaces all render the same `.board-list` tiles, and the add tile is itself an
`a.board-list-item.label`, with `.is-template-container` for the Templates tab.
NOTE on the request: "+ Add board at 1/2 and a board icon at 1/4 of current"
cannot also make them equal, since they start at different heights (128px vs
~114px declared, more as rendered). Equal height is the part that is
unambiguous, so both are set to 4rem - exactly half the board tile's previous
height. Say the word if they should be shorter still (2rem = 32px fits one line
of title).
Thanks to xet7 !
The avatar dropped to a second line even with space left beside the bell, because
a width-based rule forced `flex-wrap: wrap !important` on the quick-access bar -
added deliberately, with the comment "so ~7 items fit in two wrapped rows". An
!important wrap beats any nowrap, so the earlier one-row work never took effect
at small width; and a wrapping flex row breaks BEFORE the last item rather than
shrinking anything, which is why the avatar went down while empty space stayed
behind on row one.
Every flex-wrap rule on that bar is now nowrap (verified by listing all eight),
and the items are made to fit rather than the row made to grow. `overflow:
visible` is kept, so a long translation or a custom logo spills instead of
disappearing.
The username/full name beside the avatar is also hidden at small width, as
reported. The template already hides it `unless isMiniScreen`, but that is a
JS/Session decision - Utils.isMiniScreen() also weighs mobile mode and the device
- so it can be true while the bar is narrow, and a full name is easily 100px+ of
a 375px bar. Same bare-text-node situation as the home link: font-size:0 on the
link collapses the name, and the avatar keeps its own size (with a font-size
restored on the avatar wrapper so initials avatars, which have no size of their
own, do not vanish with it). The name stays in the DOM for screen readers.
Measured budget for an iPhone 12 mini is now 328px of 375px.
Thanks to xet7 !
The label was still visible on iPhone and Fairphone 4. The rule that was supposed
to hide it (added in the one-row commit) carried no !important, and ELEVEN other
rules in header.css set a font-size on that same link - most of them !important,
including three scoped to the All Boards page itself via `body:not(.board-view)`
/ `.wrapper ~`, and one setting `16px !important; /* Much larger text */`. Every
one of them beat it, so the label kept showing on exactly the page it was
reported on.
The fix is a block at the END of header.css that uses !important and repeats each
competing selector shape (plain, `.wrapper ~`, `body:not(.board-view)`, and the
three `.iphone-device` variants), so where specificity ties, source order decides
in favour of hiding. Enumerating every font-size rule that touches
`.home-icon a` confirms this one is last: the competing !important rules end at
char 36958 and this one is at 47542.
Keyed on WIDTH (max-width: 800px), which is what was asked for - all smartphones,
small width. The viewport meta is `width=device-width`, so an iPhone 12 mini
reports 375px and a Fairphone 4 about 360px; both match. The separate
`body.mobile-mode` rule still covers the explicit phone/desktop toggle at any
width.
Also trims the notification bell, which sat in 36px of margin around a 28px icon:
10px on each side of the button (notifications.css) plus 0.5rem on each side of
its `#notifications` wrapper from the mobile blocks. More empty space than icon,
and on a 375px bar it is space the other buttons need. Both layers now give 2px a
side, which takes the measured one-row budget from 342px to 320px of 375px.
Thanks to xet7 !
The previous commit hid it on a narrow VIEWPORT (a media query) and on
`.iphone-device`. Mobile MODE is a different thing: `body.mobile-mode` is set by
Utils.applyMobileMode() from the phone/desktop toggle in this same bar, it is a
deliberate user choice, and it applies at any width - so on a wide screen in
mobile mode the label was still there. That is what was asked for: mobile mode,
not a viewport width.
`body.mobile-mode #header-quick-access .home-icon a` (1,2,2) beats the base
`#header-quick-access .home-icon a` (1,1,1), so no !important is needed for this
path; the `.iphone-device` path already has its own override, appended after the
two competing `font-size: 1em !important` rules so the later one wins.
The label is a bare text node inside the link, not a span, so it cannot be
selected on its own: font-size:0 on the link collapses it and the icon's own
font-size brings the icon back. The text stays in the DOM, so screen readers and
the accessibility tree still announce "All Boards".
Thanks to xet7 !
On an iPhone 12 mini (375px) the bar wrapped to two rows: home + logo +
mobile/desktop toggle on the first, drag-handle toggle + zoom + notifications +
user menu on the second. The mobile CSS chose that on purpose - the comment said
a nowrap row overflowed and `overflow: hidden` clipped the right-hand items - but
it treated the symptom. The row did not fit because of what was IN it:
* the home link kept its full "All Boards" label, the single widest item in the
bar and longer still in most languages ("Kaikki taulut");
* the logo was allowed 120px of a 375px bar;
* TWO items had `margin-inline-start: auto` (zoom and the user bar). An auto
margin absorbs all remaining space on its line, so the first one filled row 1
and pushed everything after it onto row 2 - that alone forced the wrap;
* items carried 8px gaps and, on the `.iphone-device` path, 0.5rem margins on
BOTH sides: ~80px of margins across five items.
The row now fits instead of wrapping: the home link is icon-only, the logo caps
at 84x20, there is exactly ONE auto margin (on the user bar, so it still sits at
the end when there is room), gaps are 6px and per-item margins 3px. Measured
against the declared sizes that is 342px of 375px, leaving ~33px of headroom.
The home LABEL is a bare text node, not a span, so it cannot be selected
directly: `font-size: 0` on the link collapses it and the icon's own font-size
brings the icon back. The text stays in the DOM, so screen readers still announce
it.
Both paths had to change together. `.iphone-device` is added by boardBody.js, so
it is present on a board page and ABSENT on All Boards (the screen in the report),
and its rules set font-size and per-item margins with !important - without the
matching override the bar would have stayed two rows on a board page and changed
height when navigating between the two screens.
Thanks to xet7 !
The dev-server option added in the previous commit stripped the scheme off the
answer and always appended the listen port, so "https://wekan.example.com" became
"http://wekan.example.com:4000". Behind a reverse proxy that is wrong twice over:
Caddy serves https://wekan.example.com on 443 and forwards to localhost:4000, so
the public URL has no port and is https, and nothing is listening on
wekan.example.com:4000 at all. Meteor builds absolute URLs from ROOT_URL, so
every e-mail link, OAuth redirect and attachment URL would have pointed there.
The listen port and ROOT_URL are now treated as the different things they are.
The port is appended ONLY when the dev server is browsed directly:
<empty> -> http://localhost:PORT (port appended)
wekan -> http://wekan.localhost:PORT (port appended)
https://wekan.example.com -> used EXACTLY as given (no port, https
kept, an explicit port kept if there is one)
wekan.example.com -> https://wekan.example.com (no port; a
dotted name is assumed to be proxied)
A trailing slash is stripped so built URLs do not double up, and the prompt now
says which answers are local and which are public. WEKAN_DEV_ROOT_URL is the
non-interactive form (WEKAN_DEV_HOST still works).
Verified by sourcing ask_dev_url for all eight cases, including the reported one:
port 4000 + https://wekan.example.com now yields exactly
ROOT_URL=https://wekan.example.com with Meteor listening on 4000.
Thanks to xet7 !
The Dev server menu could only run on localhost:3000, on the current IP, or on a
custom IP:PORT. There was no way to run on a different local port with a
different ROOT_URL host without editing the script.
The new "CUSTOM PORT + SUBDOMAIN" entry asks for both and uses them. ROOT_URL is
not cosmetic: Meteor builds absolute URLs from it (e-mail links, OAuth redirects,
attachment URLs), so a subdomain setup has to be told about it or those links
point back at localhost.
The host answer takes either form:
<empty> -> localhost
wekan -> wekan.localhost (a BARE label becomes a subdomain of
localhost; browsers and systemd-resolved resolve
*.localhost to 127.0.0.1 with no /etc/hosts entry)
wekan.example.com -> used AS-IS, with a note that it must resolve here
A pasted URL is reduced to its host (scheme, path and any port stripped), a
non-numeric or out-of-range port falls back to 3000 with a message, the chosen
port is freed first with kill_meteor_on_port like the other dev options, and
WEKAN_DEV_PORT / WEKAN_DEV_HOST skip the matching prompt so the option can be
scripted.
Verified by sourcing ask_dev_url against fake input for all seven cases above.
Adds tests/rebuildWekanDevServer.test.cjs as a source guard for this and for the
inotify watch-limit check added earlier in the same script - that it runs before
the menu, never exits, is overridable, and no-ops on macOS/BSD.
Thanks to xet7 !
"Show desktop drag handles" did nothing on a touch screen. The rule was
isTouchScreenOrShowDesktopDragHandles() = isTouchScreen() || preference
so on touch the OR was already true and the toggle could never hide the handles.
Every place that decides whether to render a handle - minicard, list header,
swimlane header - and every sortable handle selector goes through that one
helper, so the setting was inert on exactly the devices that show handles.
The setting is now THREE states, not two: on, off, and never-chosen. An explicit
choice always wins (including OFF on a touch screen); only when the user has
never chosen does the device decide, and then a touch screen still gets handles
by default, because a finger needs something to grab. The rule lives in the pure
models/lib/dragHandles.js so it can be unit-tested, and the toggle now stores a
real `false` instead of removing the setting - that is what lets "turned off" be
told apart from "never chosen". toggleDesktopDragHandles takes the explicit new
state from the client (which alone knows whether this is a touch device) and
still accepts no argument for older clients.
Handles also decide what a DRAG MEANS, and that half was broken too: `.minicard`
and `.list-header` carried `nodragscroll` unconditionally, so with handles ON a
finger dragging across a card neither moved the card (only the handle does) nor
panned the board (dragscroll was opted out) - it did nothing. They now opt out
only when handles are OFF, i.e. only when the element IS the drag source. With
handles on, the card body pans the board, which is the whole point of having
handles.
And the handle has to be reachable with a finger: it was a 20-28px icon in the
bottom-right corner, a mouse-sized target that is close to unusable on a
wall-mounted infoscreen. On a coarse pointer it becomes a 48px full-height strip
down the leading edge (the Material minimum, and the easiest edge to thumb), with
the card content padded to match. A mouse keeps the compact corner handle, since
`pointer: coarse` does not match a mouse.
Tab order: the keyboard card/list move buttons are focusable but `opacity: 0` and
sit at the START of the card content, so tabbing went card (visible focus) ->
invisible -> invisible -> next card and the focus ring kept vanishing and
reappearing where it looked like it had gone backwards. They are now revealed
while focused, the same pattern the skip-to-content link already uses.
Adds tests/dragHandles.test.cjs: the three states, that an explicit OFF hides
handles on touch (the reported bug), that an explicit choice always beats the
device default, and that a corrupt stored value falls back to the device default
rather than leaving a finger unable to drag.
Thanks to xet7 !
Meteor's file watcher takes ONE inotify watch per DIRECTORY, and the limit
(fs.inotify.max_user_watches) is per USER, shared with every other watcher that
user runs - an editor is usually the other big consumer. On a stock kernel it is
8192 or 65536, which a WeKan checkout can reach on its own. When it runs out,
Meteor fails with a message that blames the disk and sends people looking in the
wrong place:
Failed to start watcher for <repo>: [Error: inotify_add_watch on '<path>'
failed: No space left on device]
ENOSPC from inotify_add_watch means the WATCH LIMIT is exhausted, not that the
disk is full.
ensure_inotify_watches() now runs on every invocation, before the menu. If the
limit is below 524288 (the value VS Code documents for the same problem) it
raises it with sysctl for this boot and persists it to
/etc/sysctl.d/60-wekan-inotify.conf so the next boot does not go back to failing
builds. It also raises fs.inotify.max_user_instances from the low stock 128 to
1024, since each watcher process needs an instance and editors + Meteor +
chokidar add up. Each watch costs ~1 KB of kernel memory only while in use, so a
high ceiling is a limit, not a reservation.
It never aborts the script and never fails a build:
* already high enough -> silent no-op, the conf file is not touched
* root, or passwordless sudo -> applied without prompting
* sudo with a TTY -> prompts once
* no root and no usable sudo -> prints the exact two commands to run by hand
* WEKAN_INOTIFY_WATCHES=0 -> skipped entirely (any value overrides 524288)
* macOS/BSD -> returns immediately, there is no inotify there
Verified against a fake /proc + fake sysctl/sudo for all six paths above.
Thanks to xet7 !
`meteor` failed with
Failed to start watcher for /home/user/repos/wekan: [Error: inotify_add_watch
on '.../.tools/node-v24.18.0-linux-arm64/include/node/openssl/archs/
BSD-x86_64/asm_avx2' failed: No space left on device]
ENOSPC from inotify_add_watch means the per-user inotify WATCH LIMIT is
exhausted, not that the disk is full - the disk is 64% used with 157 GB free.
Meteor's watcher takes one inotify watch per DIRECTORY, and this repo had 41,040
of them against a fs.inotify.max_user_watches of 65536 that is shared with every
other watcher the same user runs (editors included). Two trees that are not app
code accounted for 72% of that:
.tools/ 20,535 dirs, 4.1 GB - a full Node 24 install (headers for every
openssl arch), a Go toolchain with its module/build caches, build
logs and repro dirs
FerretDB/ 9,148 dirs, 3.4 GB - the FerretDB v1 fork checkout, a complete Go
project plus its docs
Both are already in .gitignore, but the watcher only honours .meteorignore, so
Meteor kept walking and watching them. Nothing in WeKan imports from either (the
FerretDB binary is downloaded from its GitHub releases at build time), so there
is no reason to watch or scan them.
Excluding both takes the watched directory count from 41,040 to 11,213, which
also leaves headroom for the editor's own watches.
Thanks to xet7 !
cpu-exec exists so that a binary needing an instruction-set feature the CPU does
not have (AVX masked by a hypervisor - QEMU/KVM/Proxmox, the reported #6458
environment - an old CPU, or ARMv8.0 on a Raspberry Pi) runs through bundled
qemu-user instead of dying instantly with SIGILL. With no features declared it is
a plain exec, so it is safe and free to route EVERY binary through it - which is
why the design is "route everything".
Two platforms were not doing that:
* Sandstorm SHIPPED cpu-exec and qemu-x86_64 (sandstorm-src/build-deps.sh) but
the grain launcher spawned all eight bundled binaries directly - ferretdb,
mongod 3.0 (twice), niscud, the legacy mongo CLI (twice) and node for the
bridge and the importer. So the safety net was in the package and unreachable,
on the platform with the LEAST control over its hardware: a grain runs on
whatever CPU the Sandstorm host has.
* The snap routed mongod (mongodb-control, migration-control) but not FerretDB
(ferretdb-control, both the external-DB and SQLite launches) and not node
(wekan-control: the main application start and both maintenance-page starts).
Both now route through cpu-exec, each with a direct-exec fallback so an older
deps image or snap revision still works. On Sandstorm the guard also requires
/bin/bash, since cpu-exec is a bash script; without it the binary runs directly
exactly as before. The snap's main start keeps its `ulimit -s 65500` - the limit
is set before the exec and inherited across it (verified by expanding the line).
Docker (releases/ferretdb/wekan-entrypoint.sh) and the bundle launcher
(releases/ferretdb/start-wekan.sh) already routed ferretdb and node, and were
checked for other unrouted launches - there are none.
tests/cpuExecWiring.test.cjs previously asserted only that the Sandstorm build
SHIPS cpu-exec, which is exactly how the gap survived: it now asserts that the
grain launcher routes each of the six bundled binaries, that no bundled binary is
spawned directly any more (/bin/sleep is a grain utility, not bundled, so it is
exempt), and that the snap routes FerretDB and node with their fallbacks intact.
Thanks to xet7 !
Five mocha suites sat in the tree looking like they were being run, and were not:
`meteor.testModule` points at client/lib/tests/index.js and
server/lib/tests/index.js, those indexes list their suites with explicit imports,
and these five were never added. server/lib/tests had 49 suite files but 48
imports.
Two of them are *bleed security regression suites - checklistbleed (cross-board
checklist/checklist-item move denial) and proxybleed (header-login trusted-source
and request-IP handling) - exactly the kind of test whose silent absence lets a
fixed vulnerability come back unnoticed. The other three are filenameTruncation,
alwaysShowCodeAsText and renderLinksPlainText.
All five are now imported by their index. Every symbol they import was checked to
still exist first: denyCrossBoardMoveByCard / denyCrossBoardMoveByChecklistItem
(server/lib/utils.js), getRequestIp / isTrustedHeaderLoginSource /
findOrCreateHeaderLoginUser (server/lib/headerLoginAuth.js),
truncateFilenameToBytes / sanitizeFilename (models/lib/filenameSanitizer.js),
getSecureDOMPurifyConfig / sanitizeHTML (imports/lib/secureDOMPurify.js) and the
Markdown export of the wekan-markdown package. They have never run in this state,
so they may still fail on their assertions - that is the point of running them.
tests/testsAreRegistered.test.cjs is added as a guard: it fails if any
*.tests.js file in either directory is not imported by its index, and names the
two *bleed suites explicitly so a future tidy-up cannot drop them again quietly.
Also deletes files that nothing loads:
- client/components/main/responsiveFixes.css (162 lines, imported by nothing, so
never in the bundle - package.json sets meteor.mainModule, which disables
Meteor's eager loading).
- models/backgrounds.js, models/backgrounds.server.js and
server/permissions/backgrounds.js - three empty tombstones whose only content
was a comment saying board backgrounds became board-level Attachments and the
file is "intentionally empty and no longer imported". The live paths
(server/boardBackgrounds.js, server/publications/backgrounds.js) are different
files and are untouched.
Thanks to xet7 !
The section had grown two 'and fixes the following bugs:' headers and both a
'developer-tooling fixes' and a 'developer-tooling addition' header, because each
new entry was added with its own heading. The subsection headers are meant to
read as ONE flowing sentence with each verb appearing once, so the nine bullets
are now grouped under: adds new features, fixes bugs, removes dead code, has
developer-tooling changes. No bullet was changed and all nine commit links are
still present.
Thanks to xet7 !
Every CHANGELOG bullet links the commit it describes, and those links are written
BEFORE the release. Anything that rewrites history in between - a rebase onto an
upstream change, an amend, a squash - changes the hashes, so every link in the
not-yet-released section points at a commit that no longer exists and 404s once
pushed. That just happened to all eight links of the current Upcoming section.
release-all.sh now checks them as its first local step, before the Upcoming
heading is renamed and before the release commit is made, so the repair is part
of that commit:
- a hash that is still an ancestor of HEAD is left alone;
- a stale one is resolved by reading the OLD commit's subject (the pre-rewrite
object is still in the clone, reachable from the reflog) and finding the commit
on this branch with exactly that subject - the rewritten copy of the same
commit - then repointing the link to it;
- the substitution is bounded to the section being released, so the same hash
quoted in an older, already-pushed entry is never touched;
- it works whether or not the "# Upcoming" heading has already been renamed,
falling back to the newest release heading;
- anything it cannot resolve is reported as a WARNING and left as-is. A broken
doc link is never a reason to abort a release, so the repair never exits
non-zero.
Verified by running the function against fixture CHANGELOGs in this repo, using
the real pre-rebase hashes: two stale links were remapped to their rewritten
commits, an already-correct link was left alone, an unknown hash was reported and
kept, the identical stale hash in an already-released section was NOT rewritten,
and the already-renamed-heading path was exercised too. Adds
tests/changelogCommitLinks.test.cjs as a source guard for those properties.
Thanks to xet7 !
The eight Upcoming entries still linked the pre-rebase commits, so every link
would have 404ed once pushed. Each hash was remapped by matching the commit
subject against the commits now on this branch.
Thanks to xet7 !
This app runs with the audit-argument-checks package, so any Meteor method that
RECEIVES an argument it never check()s throws
"Did not check() all arguments during call to '<method>'" - the call fails
entirely, no matter what the method would have done.
problemDetailReport(area) had that defect but nothing had ever passed it an
argument, so it went unnoticed until the new Admin Panel / Problems / CPU usage
header started polling problemDetailReport('cpu') every 5 seconds and the server
log filled with the exception.
Auditing every server method for the same defect found five more that ARE called
with arguments from the client, so these features were failing outright:
- unlockUser(userId) - Admin Panel / People, unlocking a locked-out user
- runBackup(opts, storageName) - Admin Panel / Attachments, running a backup
- restoreBackup(zipPath, mode) - restoring a backup
- saveBackupSchedule(schedule) - saving the backup schedule
- migrateTextDatabase(direction) - the MongoDB <-> FerretDB text migration
and one with no current client caller, getServiceConfiguration(service), fixed
for the same reason.
Each now check()s its arguments against the types its call sites actually pass
(the two optional ones use Match.OneOf(String, null, undefined)), and the three
files that had no check import got one.
Thanks to xet7 !
Nothing scheduled it and nothing rendered it, but every logged-in client still
paid for it:
- initializeCronJobs() (server/cronMigrationManager.js) was NEVER called, so the
SyncedCron.add() registrations and the 5s job-queue processor never started.
- boardMigrationDetector.start() sat behind a commented-out Meteor.startup hook,
with the note "Automatic migration detector is disabled - migrations only run
when opening boards".
- The Admin Panel had no Cron page at all: no route in config/router.js, no
button in settingHeader.jade, no template ever included, and every helper,
event and reactive var for it commented out in settingBody.js.
- Yet imports/cronMigrationClient.js WAS imported by client/imports.js, so every
client subscribed to three publications and polled cron.getMigrationProgress
every 10 seconds, forever, for a feature with no user interface.
Migrations already run - and are already reported - through the paths that work:
Admin Panel -> Attachments (database migration) and the on-board-open repair,
both driven by the shared migrationProgress overlay dashboard mounted app-wide in
defaultLayout, plus the in-progress list on Admin Panel -> Problems -> Summary.
Removed: cronSettings.jade/.css, imports/cronMigrationClient.js,
models/cronJobStatus.js, server/cronMigrationManager.js (28 admin-gated cron.*
methods that no UI called), server/cronJobStorage.js,
server/boardMigrationDetector.js and the three publications that fed only the
deleted client module (cronJobs, cronMigrationStatus, migrationProgress).
KEPT on purpose: server/cron/syncedCron.js, which is SyncedCron itself and is
used by the backup schedule (server/methods/backup.js) and scheduled rules
(server/scheduledRules.js).
getInProgress() in server/lib/systemStatus.js no longer reads cronJobStatus.
Leaving that check would have been worse than useless: a leftover
status:'running' doc from an older version now has nothing to clear it, so
Admin Panel -> Problems would report "Migration job X running" forever.
The 40 i18n keys that only the deleted template used are left in place - dropping
them from every language file would discard human translations for keys that may
be reused.
Thanks to xet7 !
After importing a Trello board and choosing to map users later, "Map to existing
user" listed only the admin: the picker offered nothing but the ACTIVE REAL
MEMBERS of the board, and right after an import the real people have no
membership at all - the placeholders do. There was no search box either, so on a
board whose only real member is the importing admin there was literally nobody to
pick.
The picker now has a search box that goes through the same permission-checked
`searchUsers` method the normal add-member typeahead uses, so the same board
membership check and the same #6116 same-org/team restriction apply. With the box
empty it still lists the board's real members (the common case, which changes no
roles at all); typing searches every real user and labels the ones who are not on
this board yet.
Mapping onto a user who is not a board member adds them to the board with the
PLACEHOLDER's OWN role - the role the import recorded for that person - never a
higher one, and only after passing exactly the checks inviting them would: the
Admin Panel "roles allowed to invite" setting, the same-org/team restriction, and
the refusal to add a deactivated account. Adding a member with a chosen role is
something the board admin doing the mapping can already do through the normal
add-member flow, so this grants no capability the caller did not have; an
existing active member is still left completely untouched, entry and role.
Also fixes sanitizeUserForSearch dropping `profile` from every search result: it
read the Mongo-style paths in its allowlist ('profile.fullname') as FLAT keys, so
the lookup was always undefined and both this picker and the add-member typeahead
showed a blank name with only the username in brackets. Dotted paths are now
copied into the same nested shape, still allowlisting exactly the listed leaves.
Adds positive and negative unit tests for the new planner contract, including
that a comment-only placeholder can never yield an admin, that reactivating an
inactive membership does not duplicate the entry, and that the invite policy runs
before any write.
Thanks to AmigaAbattoir and xet7 !
Fixes#6519,
The page listed only PAST high-CPU periods (the event rows written by the CPU
monitor), so it could not answer "what is the CPU doing right now?" at all - the
one question an admin opens that page to ask.
A live line now sits between the page title and the search box: the current
system CPU percentage, the core count, the 1/5/15 minute load average and the
coarse "what WeKan is doing" label, refreshed every 5 seconds and outlined in red
while the monitor considers the CPU sustainedly high.
The figure comes from getCurrentCpu() in the CPU monitor, which reads the same
sample the monitor writes its event rows from, so the header and the rows below
it can never disagree. It reads module state only - no sampling of its own - so
polling it is cheap. When the background monitor is disabled
(WEKAN_CPU_MONITOR=false) it would otherwise always read 0%, so in that case the
percentage is measured between calls using a SEPARATE baseline, which cannot
disturb the monitor's own delta, and `monitored: false` is reported alongside.
Thanks to xet7 !
The Summary page reported "Broken cards N" and told the admin to "open the board
to auto-repair, or run the repair migration", but there was no button anywhere to
run one - and worse, no repair in the app could actually clear that count.
countBrokenCards() counts every card missing a boardId OR a swimlaneId OR a
listId. repairAllBoards() walks only NON-ARCHIVED boards and only ever sets
swimlaneId, so three kinds of counted card could never be repaired by anything:
cards on an archived board, cards with a missing listId, and cards with no
boardId at all. The count sat there forever with nothing to press.
The new repairBrokenCards method (admin only) runs the standard per-board pass
and then closes those gaps: orphaned-swimlane cards on archived boards, and cards
missing a listId and/or swimlaneId on any board, are assigned to that board's
first usable list/swimlane (creating a default one if the board has none). Each
board resolves its default list/swimlane once rather than once per card. Cards
with no boardId cannot be placed on any board - guessing would drop a user's card
onto an unrelated board - so they are reported back as `unfixable` and left
alone, never deleted, and the result line says so instead of leaving a count that
never reaches zero unexplained.
What counts as broken now lives in one pure module, models/lib/brokenCardsRepair.js,
used by BOTH the count and the repair, so they can no longer drift apart and
leave the admin pressing a button that does not move the number. Progress is
persisted through setBoardRepairStatus, so a running repair shows up in the same
"in progress" list as the startup pass.
Adds unit tests (positive + negative) for the shared rule, including the
regression itself: every card the count reports as broken must be either
repairable or explicitly unfixable, never silently neither.
Thanks to xet7 !
The report already paginates server-side (25 rows per page via limit/skip), so it
never loaded all cards into the browser, but two things made it feel like it did:
1. The cardsReport publication sent WHOLE card documents - description,
customFields, vote/poker sub-documents, every date field - when the table
renders only six columns. A 25-row page could be hundreds of kilobytes on
boards with long descriptions. It now projects title, boardId, listId,
swimlaneId, members and assignees only.
2. Every prev/next click re-ran the report's count method as well as
re-subscribing. getCardsReportCount counts EVERY card in the database, and the
total cannot change just because you moved to the next page, so each click
paid for a full collection count plus a second server round trip. loadReport()
now takes a `recount` flag: opening a report and searching in it recount,
plain paging does not.
Both changes apply to the other paginated admin reports too (files, rules,
boards, impersonation, recovery), which share loadReport().
Thanks to xet7 !
client/components/settings/adminReports.css was not imported anywhere, and
package.json sets meteor.mainModule, which disables Meteor's eager loading - so a
CSS file that nothing imports is simply not in the bundle. None of the Admin
Panel report styling was applied, and the prev/next buttons fell through to the
global rule in forms.css:
button { background: var(--theme-accent, #000) }
which is BLACK when no custom theme colour is set. Import it from
client/features/settings.js next to the other settings stylesheets.
Also add client/components/main/paginationControls.css: one themed look for
EVERY prev/next control in WeKan (admin reports, people/org/team/domain, All
Boards, board Table view, cron tables). forms.css also styles button:focus
(var(--theme-accent, #222)) and button:active (#111 / #e6e6e6) at a specificity
equal to or higher than a plain `.some-pagination button` rule, so even a loaded
stylesheet lost as soon as the button was clicked: pressing "next" left it with a
dark grey or grey background until it lost focus. Every state is now spelled out
at a specificity that beats the global rules, all colours come from
--theme-accent with WeKan blue as the fallback, disabled is the same themed
outline faded rather than a grey block, and the "3 / 42" page info inherits the
surrounding text colour instead of a hard-coded #333 that vanishes on dark
backgrounds.
Thanks to xet7 !
pull-security-reports.sh saves every report GitHub exposes for a repo - open AND
closed - into a timestamped run directory with one subdirectory per category of
the GitHub Security tab (CodeQuality/StandardFindings, CodeQuality/AIFindings,
CodeScanning, Dependabot/Vulnerabilities, Dependabot/Malware, SecretScanning,
Advisories, DependencyGraph), each split into open/ and closed/, as raw JSON plus
readable per-rule / per-file / per-severity text summaries.
Each category is fetched ONCE with no state filter and split locally with jq, so
open + closed are a partition of one snapshot instead of two requests taken at
different moments. A failing endpoint (feature disabled, missing token scope) is
recorded in 00-summary.txt and skipped rather than aborting the run.
Two safety properties: the secret-scanning API returns the live credential in
.secret, which is deleted before anything is written, and the reports root gets a
.gitignore excluding everything - these files describe unfixed vulnerabilities in
a public repo.
Needed because the VSCode Flatpak sandbox has neither gh nor network access to
api.github.com, so the reports have to be pulled on the host and read from disk.
Thanks to xet7 !
A SHARED list (empty swimlaneId) renders under every swimlane. cardsCount()
scoped the count by `list.swimlaneId`, which is '' for a shared list, so every
swimlane showed the whole-list count while the cards rendered below were
swimlane-scoped — e.g. "5 Cards" over an empty second swimlane. The card body
already scopes by the container swimlane via listBody.jade `idOrNull ../../_id`;
cardsCount() now takes that same `../../_id` (passed from listHeader.jade) and
prefers it over the list's own binding, so the header count matches the cards
actually rendered in that swimlane. Still gated to swimlanes view (lists view
keeps the whole-list count), and both list.cards(id) and lazyListCardCount(id)
already scope by the passed swimlane id (incl. first-swimlane shared/orphaned
surfacing), so the count is correct in both eager and lazy (#6480) modes.
tests/cardsCountSwimlaneScope.test.cjs guards the wiring; the per-swimlane card
set is covered by server/lib/tests/selectAllSwimlane.tests.js.
Thanks to xet7 !
@wekanteam/dragscroll attaches its mouse handlers PER element inside reset(),
so reset() must be re-run after the set of .dragscroll containers changes. In
boardBody.js reset() ran in onRendered (once) and in one autorun whose only
reactive deps were the touch/permission reads, NOT the swimlanes/lists. So
when swimlanes/lists rendered after onRendered — adaptive lazy card loading
(#6480), the on-open data-repair adding a default swimlane (#6484), or a board
switch that reuses this template instance without re-firing onRendered (the
#4978 case) — the new containers never got mouse handlers, so mouse/touchpad
drag-scrolling was dead and lower swimlanes could not be reached by dragging
(touch still worked via the document-delegated dragscrollTouch). The reset
autorun now reads the board view + swimlanes + lists, so it re-runs and
re-attaches whenever the rendered containers change. The reads perform no DB
writes, so there is no autorun write loop.
tests/dragscrollReattach.test.cjs source-guards the reactive reads before
reset(). Runtime UI behaviour still needs confirmation in a browser.
Thanks to xet7 !
The OpLog ts index is now created best-effort on postgresql/mysql/hana
(with a MariaDB generated-column fallback), and the MariaDB-vs-mysql-backend
assessment is complete. What remains is live-EXPLAIN index-usage
verification on each engine, which the sandbox cannot do.
Thanks to xet7 !
Later subsections in a release now start with a lowercase "and ...:" instead
of repeating "This release ...:", so a multi-subsection release reads as one
sentence (matching v10.21's existing style): Upcoming, v10.30, v10.29, v10.22,
v10.14 and v9.99. The v10.23 security header now says "CRITICAL SECURITY
ISSUES" (the wording previous releases use) instead of "CRITICAL
VULNERABILITIES". CLAUDE.md documents both conventions.
Thanks to xet7 !
Records the remaining direct, no-service translation work (142 languages,
12254 strings) as deferred, since bug fixes are more important than
translations. The #6494 tooling that makes the fill safe is already committed.
Thanks to xet7 !
Removes the machine-translation service (machine-translate.mjs) that called an
external endpoint (LibreTranslate/DeepL) and needed WEKAN_MT_URL / WEKAN_MT_API_KEY.
It did not work and could put a machine string where a human translation belonged.
Now the strings still untranslated everywhere (equal to the English source after the
Transifex pull + merge) are translated DIRECTLY — the maintainer/assistant writes the
translation using that language's existing translations and general kanban terminology
as the reference. No external service, API, endpoint, key or password.
- releases/translations/fill-translations.mjs (new): --missing lists the per-language
count still untranslated; --list <lang> dumps the placeholder keys to translate;
--apply <lang> file.json writes translations ONLY into placeholder keys, so it can
never overwrite a human translation, and ignores any value still equal to English.
- releases/translations/pull-translations.sh: drop the WEKAN_MT machine-service hook;
after the pull+merge it now prints what remains to translate. The pull always fetches
the newest Transifex translations FIRST (tx pull -a -f) and merge-translations.mjs
keeps/restores the human ones, so a fetch is never omitted and Transifex human
translations are never overwritten (the two-way process #6494 asked for).
- releases/translations/verify-human-preference.mjs (new): pure-logic proof (10 cases)
that the pull-merge keeps/restores human translations and a fill only touches
placeholders. Filled strings stay local and are NOT pushed to Transifex.
- CLAUDE.md: document the no-service direct-fill workflow and the human-preference
guarantee in both pull and push directions.
Thanks to s2ldan and xet7 !
Fixes#6494,
Add the missing entries so the Upcoming section details all real changes
since v10.31: the jam:offline/method/pub-sub removal, the six pre-existing
unit-test fixes, and the exact-version rspack pin (its own dependencies
entry). The #6511 ES-module fix now links all three of its commits
(collectionHelpers export {} e62c77575, and the two conversion parts
8d1fae4f7 + d6908cf41). Verified all commit links resolve and are reachable
from HEAD. Housekeeping commits (version bump, changelog edits, the
package-lock rspack re-resolution) get no bullet, per convention.
Once the client boots (after the ESM-conversion fix), jam:offline runs its
startup sync and throws
`can't access property "remove", localCollections[name] is undefined`
(jam_offline.js sync -> _keep): the server returns a collection name to
reconcile that the client never registered, because WeKan registers NO
offline collections (no .keep() anywhere) and does not use jam:method /
jam:pub-sub (no createMethod / createPublication / meteor/jam: imports).
These three packages were already removed once (0dd924f14: "not used, and
they cause too much database usage") and re-added in bf5ca3d3e. Remove them
again. The offline warning UI uses Meteor.status(), not jam:offline, so it
is unaffected. Meteor reconciles the transitive deps in .meteor/versions on
the next build.
These failed before the ESM conversion and are unrelated to it:
- addBoardTileHeight: the .path-right slice window was 1600 chars but
js-board-search-input is at offset 2517 after the header grew; widen to 3000.
- listWidthDefaults: isValidListWidth(269) is TRUE (269 >= MIN 200, no upper
bound); drop 269 from the "invalid widths" list.
- uiDensity: the js-open-board-menu cog moved to sidebar.jade; read that file.
- exporterBackpressure: the leaky-pattern guard matched the pattern quoted in
an explanatory comment; strip // comments before matching.
- adminReportsPagination: a 6th report section was added; expect 6
.admin-report-controls, not 5.
- fileTypeCorrection (real fix): streamHeaderToTemp unlinked the partial temp
file fire-and-forget, racing the async write-stream open, so a caller could
still see the file after the rejection. Remove it only after the write stream
has closed, then reject.
Remaining known failure: rulesApiTriggerNormalize (#2674 $in-matching) — left
for a maintainer decision on the intended rule-normalization contract.
Update the entry to reflect the complete fix: not just collectionHelpers,
but a transitive conversion of every client-bundled module.exports helper
to export, plus the exact-version rspack pins.
A transitive walk from client/main.js found the remaining CommonJS
(module.exports) helpers that the rspack client build pulls into the ES
module graph and rejects: 3 client/lib helpers (cardDragGeometry,
inlinedFormManager, popupOffset), 4 imports/lib helpers (boardAutoScroll,
datePickerTime, fileNameDisplay, staleWhileRevalidate), imports/simpleSchema
(its meteor/aldeed:simple-schema require becomes a namespace import),
imports/i18n/loadHelpers, and 4 more models/lib helpers (cardLinkRedirect,
sandstormAutoOpen, securityCategories, securityLogFormat). All become
`export { ... }`; their .cjs unit tests use `await import(...js)`.
The only CJS files still reachable in the walk are server-only: the
server/lib/* files (Meteor never bundles server/ to the client) and the
fs-using models/lib file-storage helpers (reached only via the server-side
fileStoreStrategy; they would fail on require("fs") if they were actually in
the client bundle). Those correctly stay CommonJS.
Full tests/*.test.cjs suite: same 7 pre-existing failures, no new ones.
The rspack client build treats a `module.exports` file imported into the
client bundle as an ES module and throws
"ES Modules may not assign module.exports" at evaluation time, aborting
the whole client module chain (No such template: swimlane / notifications
/ boardButtons, blank board, missing top bar). This is not an rspack
version regression (the lockfile has pinned ~1.7.x since v8.40); it is
that WeKan added CommonJS helpers to the client bundle.
Convert the 42 client-reachable pure-logic models/lib helpers from
`module.exports = { ... }` to `export { ... }`, and calendarFilter's
internal require('./swimlaneFilter') to an import with a .js extension
(node ESM needs it; rspack/reify tolerate it). Server-only helpers that
use node built-ins (fs/path/child_process) stay CommonJS. The plain-Node
.cjs unit tests for these helpers now use `await import(...js)` (wrapped
in an async IIFE); a source-guard in importVirtualMembers was updated
from module.exports to export. Verified: the full tests/*.test.cjs suite
has the SAME 7 pre-existing failures as before this change and no new
ones.
Remove the caret ranges so a fresh npm install cannot silently drift the
bundler to a newer @rspack/core (e.g. ^1.7.11 -> 1.7.12, or the 2.x line)
that changes CJS/ESM handling and breaks the build. This is drift-prevention
hygiene; the lockfile already resolved these exact versions, so it does not
by itself change the current build.
Note: the v10.27+ "ES Modules may not assign module.exports (No such
template)" break is NOT an rspack version regression -- the lockfile has
pinned @rspack/core ~1.7.9-1.7.11 since v8.40, unchanged between the working
v10.17 and the broken v10.27. The cause is WeKan-side: CJS module.exports
files entering the client bundle. Fixed separately per file (collectionHelpers)
and, durably, by moving those client-imported models/lib files to ESM.
Add the rebuild-wekan.sh developer-tooling bullet (ss fallback so the dev
server can be stopped when fuser/lsof are absent), and expand the #6511
fix entry to also cover #6514: jullbo (plain Docker, no reverse proxy,
ROOT_URL=http://neptun:4001) and AmigaAbattoir confirmed the identical
"ES Modules may not assign module.exports: 43130" -> "No such template:
swimlane / notifications / boardButtons" failure, i.e. the same global
collectionHelpers module-format bug fixed by export {}. jullbo also
confirmed the #6515 listsUnbound fix works.
Close#6514 as a duplicate of #6511 (same root cause, same fix).
Thanks to jullbo, AmigaAbattoir and xet7 !
Close#6514,
free_tcp_port() killed the process holding a port only via fuser (psmisc)
or lsof. On a minimal Linux that has neither installed, it did nothing —
yet port_in_use() detects the port via ss, so the stop loop kept
reporting "still in use" and finally "ERROR: Port 3000, 8080 or 3001 is
still in use ... Stop it manually and retry", and the dev server could
not restart. Add an ss fallback: parse the owning pid from
`ss -ltnpH "sport = :PORT"` (works for your own process without root) and
kill it. ss is part of iproute2 and effectively always present on Linux.
The earlier #6512 fix covered only the useraccounts password/register flow
(onSubmitHook). OAuth / OIDC logins use the redirect login style and do not
go through onSubmitHook: after returning from the identity provider the user
is logged in but still on the sign-in route, which renders only the language
selector ("Vaihda kieltä") until a manual page reload.
Add a client Accounts.onLogin handler (fires for every login method after
Meteor.userId() is set) that navigates to All Boards when the current route
is an auth route. Guarded to auth routes so an auto-login on a deep-linked
board URL is not redirected away, and it is a no-op after password login
(onSubmitHook has already navigated).
Thanks to xet7 !
Fixes#6512,
v10.31 was released, so the #6511 fix (collectionHelpers.js: export {}
instead of module.exports = {}, which stopped the whole client module
chain aborting with "ES Modules may not assign module.exports" -> "No
such template") goes in a fresh Upcoming section above v10.31.
imports/collectionHelpers.js (a side-effect shim that patches
Mongo.Collection.prototype) ended with `module.exports = {}`. It also
references the Meteor pseudo-global `Package` BARE, which the client
rspack build - ProvidePlugin rewrites into an injected ESM `import`,
marking this file an ES module. An ES module that assigns
`module.exports` throws, at evaluation time,
`Uncaught Error: ES Modules may not assign module.exports or exports.*,
Use ESM export syntax, instead`. Because this shim is the FIRST import in
client/main.js, that throw ABORTED the whole client module chain: app
templates (swimlane, notifications, headerUserBar, ...) never registered,
so Blaze threw "No such template: swimlane" and the board stayed on the
maintenance spinner, the top user/settings bar was missing, and the login
form did not render - reproduced on Docker, Sandstorm and the official
boards.wekan.team (root domain), i.e. a global build bug, not infra. The
regression came from converting this shim to pure require()/module.exports.
Replace `module.exports = {}` with `export {}`: a clean ES module with no
CommonJS export, so no assignment throws, and it still works as a
side-effect import on the client and require() on the server. It exports
nothing, and no consumer reads its exports (both callers import/require it
only for its side effects).
Thanks to mueschel, jullbo, akshat-goel and xet7 !
Fixes#6511,
The #6512 (post-login redirect) and #6515 (per-swimlane list repair) fix
commits post-date the v10.30 release, so they were wrongly listed inside
the tagged v10.30 section. Move them into a new "# Upcoming WeKan ®
release" section above v10.30. v10.30 keeps only what was in Upcoming
before it was cut (the bundled FerretDB OpLog ts index and the #5623
test fix).
The official boards.wekan.team (root domain, correct ROOT_URL) reproduces
these, disproving the earlier sub-path/proxy and ROOT_URL-not-set
theories:
- #6511: the "No such template" cascade is a MODULE-FORMAT build error
("ES Modules may not assign module.exports: 43130") that aborts module
evaluation so templates never register — a real global rspack build
bug xet7 is fixing, not infra.
- #6512: fixed (post-login redirect race), removed from the backlog.
- #6514: reframed — the redirect-race (#6512) and module-format (#6511)
fixes are the real causes; ROOT_URL-not-set was at most contributory.
After a successful login/register, onSubmitHook navigated to the home
route immediately, but the home route sign-in guard (renderBoardList in
config/router.js) checks Meteor.userId() NON-reactively and bounces to
the sign-in page when it is still null. Right after login the client
userId lags the onSubmitHook callback by a tick, so the navigation
bounced the user straight back to the login layout — which shows only
the language selector ("Vaihda kieltä") — until a manual page reload.
The same non-reactive guard also stranded a RETURNING user on the
sign-in page during auto-login from a stored token (Meteor.loggingIn()).
- config/accounts.js: onSubmitHook now waits reactively for
Meteor.userId() before FlowRouter.go("/"), with a 5s timeout fallback
so a login that never lands userId still navigates.
- config/router.js: renderBoardList no longer bounces to atSignIn while a
login is in progress (Meteor.loggingIn()); the All Boards list fills in
reactively once userId lands.
This is the post-login-redirect part of the WeKan 10.30 login feedback;
the separate "No such template" board failure (#6511) is a module-format
build error being fixed separately.
Thanks to akshat-goel and xet7 !
Fixes#6512,
Two distinct core templates (swimlane #6511, notifications #6515
secondary) reported "No such template" at render time on different
proxy/sub-path deployments, both correctly defined in the main bundle —
so this is a client-bundle delivery / init problem on those deployments,
not a per-template source bug. Recorded so it is not mistaken for a fix
that can be made blind.
repairBoardsOnStartup ran the shared board repair over every board and,
via planBoardRepair, cleared swimlaneId to null on EVERY list that had
one -- treating any swimlane-bound list as #6484 corruption. But a list
with a swimlaneId is a legitimate PER-SWIMLANE list (rendered only in its
swimlane via swimlaneLists()), indistinguishable from a #6484-corrupted
board-wide list at the data level. So on upgrade to v10.26+ the routine
silently unbound every per-swimlane list (the reporter: listsUnbound: 24)
and all lists then rendered in every swimlane. Board open re-ran the same
repair, so even a manual swimlaneId restore in the DB was nulled again.
Remove list-unbind from the automatic plan (planBoardRepair.listsUnbind
is always empty; repairBoardData no longer issues the swimlaneId: null
write). The card repairs (missing-swimlane, orphaned) are kept. The
#6484 CODE bug that could wrongly bind a board-wide list is already
fixed, and an admin can still deliberately un-bind a specific board with
the explicit repairBoardWideLists method. Affected boards keep their
swimlaneIds now; a manual restore from a pre-upgrade backup will stick.
Tests: boardRepair.test.cjs updated to assert per-swimlane lists are
never auto-unbound and the applier no longer clears swimlaneId.
Thanks to jullbo and xet7 !
Fixes#6515,
Record the stale-test fix (50a7c8fe5) under Upcoming bug fixes so every
post-v10.29 change is reflected. The zh-TW translation update (1e73b1bef)
is covered by the standard "translators for their translations" footer,
per convention (per-language pulls are not individually bulleted).
The doubled-cards render fix (c90d6eaa4) changed
filterCardsByListAndSwimlane so shared/orphaned cards (swimlaneId
null / '' / missing / a deleted swimlane) surface ONCE, in the FIRST
swimlane, instead of in every swimlane: the first swimlane is signalled
by passing the OTHER swimlanes ids as the 4th otherSwimlaneIds argument
(what allCards() gets from orphanedCardsSwimlaneIds, which returns them
only for the first swimlane); a non-first swimlane gets no 4th argument
and returns only its own cards. That commit did not update this test, so
it still asserted the old behaviour (a bare swimlaneId returning own +
orphaned) and failed: expected [c1,c2,c5,c6,c7], got [c1,c2].
Update the test to the current contract: the FIRST-swimlane case passes
otherSwimlaneIds=[S2] and still expects [c1,c2,c5,c6,c7], and a new
NON-first-swimlane case asserts only [c1,c2]. Verified the assertions
against the exact helper logic.
Triaged all open issues created this year; none are confidently
already-fixed, so none are closed. Recorded the two not yet in the
backlog:
- #6509 (fresh v10.27 on FerretDB v2 + PostgreSQL, lists/cards not shown
until reload, undefined.remove() -- same Blaze ordered-diff class as
#6511; not closed because the identical-signature #6511 reporter says
it persists on 10.28).
- #6500 (Docker latest does not load, Connection reset by peer -- xet7 is
actively fixing the bundled FerretDB Docker startup; needs the running
Docker stack).
v10.29 was released, so this post-release note goes in a fresh Upcoming
section (not retroactively into the tagged v10.29): the bundled FerretDB
v1 fork now creates the OpLog ts index on the PostgreSQL, MySQL and SAP
HANA backends (not only SQLite), best-effort with a descriptive log if a
live engine rejects the syntax. See the FerretDB fork changelog.
Collect every real change committed after the v10.28 release into a new
"# Upcoming WeKan ® release" section above it: the snap external
PostgreSQL/MySQL/HANA FerretDB backend and the placeholder-only machine
translation step (new features), and the snap wekan.problems
settings-loading fix that makes ROOT_URL / LDAP checks read the real
config (bug fix, helps #6512 / #6514). Changelog-only housekeeping
commits (link repointing, TODO Later, version bump) are not listed.
The per-key merge (merge-translations.mjs) already guarantees a Transifex
pull never loses a human translation: it keeps the newest Transifex
translation, restores a committed human translation the pull reverted to
English, and leaves the English source ONLY on strings untranslated
everywhere. This adds the missing machine-translation step that fills
exactly those English placeholders — so machine translation can never
overwrite a human translation (a human string, value != English, is
never selected), and a language with no translation at all (every key a
placeholder) gets fully filled.
- machine-translate.mjs: placeholder-only selection (value === English
source, or key missing); pluggable LibreTranslate-compatible provider
(WEKAN_MT_URL / WEKAN_MT_API_KEY); English + en-* variants skipped;
--dry-run, --limit N (resume-friendly), --provider-check; preserves
en key order + 2-space indent + trailing newline. Machine output stays
local and is NOT pushed to Transifex.
- pull-translations.sh: run the machine step AFTER the merge, opt-in via
WEKAN_MT=1 or WEKAN_MT_URL, so a plain pull is unchanged.
#6514 and #6512 (login page shows only the language selector; header
renders empty with no user/settings menu after a 10.28 upgrade): the
reporter wekan.problems output shows ROOT_URL is not set even after
snap set root-url, which is the root cause -- a wrong/absent ROOT_URL
breaks DDP, so useraccounts never supplies the router content template
that userFormsLayout renders and currentUser stays null, while
jam:offline replays cached boards. Operational fix is to set ROOT_URL
and restart; the wekan.problems settings-loading fix in this release
already surfaces the real value. Recorded for live confirmation.
Also recorded the FerretDB v1 backend-parity in-progress work (oplog ts
index + declared-index usability across PostgreSQL/MySQL/HANA) with the
web-searched authoritative index syntax and the live-EXPLAIN
verification boundary, so the next session can resume.
The v10.28 card-sort _id tiebreaker addressed the first reported error
(Bad index in range.removeMember). The reporter now sees a different
console error, "No such template: swimlane", with the board still
showing no cards. That template is a core Blaze template compiled into
the main bundle and statically included as +swimlane in boardBody, so it
is not a lazy chunk that could 404 under a sub-path; Blaze nonetheless
reports it missing at render time. The deployment is on a /wekan
sub-path with wss .../wekan/sockjs/... 400 Bad Request plus wasm and
source-map errors, so the evidence points at the reverse-proxy WebSocket
upgrade / sub-path bundle delivery, not a WeKan source bug. Left for
live reproduction with the reporter proxy setup rather than guessing a
blind code change.
A rebase left 24 CHANGELOG commit links pointing at pre-rebase hashes
that no longer exist. Repointed each to the actual commit, matched by
subject (and, for the full-hash links, an exact issue-number anchor):
- 9 short links: template drag-to-share / GlobalAdmin REST / domain
sharing / auth-sync (#5850), snap Node.js-download 404 fix, LDAP-OAuth2
env-var docs, and the rebuild-wekan Playwright-Docker matrix.
- 15 full-hash links: #3185#3606#3624#4055#4236#4249#4394#4494#4653#4881#4946#4978#5439#5536 bug-fix entries.
Remaining older full-hash links were left as-is: an orphaned commit is
still reachable by full SHA on GitHub, and the ambiguous ones (generic
"Part 1/2" subjects, no issue anchor) need a human to confirm.
Part of bringing the non-SQLite FerretDB v1 backends to Meteor parity: let the snap run
FerretDB with a backend other than the embedded SQLite, against an EXTERNAL database the
operator hosts (the snap bundles no PostgreSQL/MySQL server).
New snap settings (snap-src/bin/config): wekan-ferretdb-handler (sqlite [default] /
postgresql / mysql / hana) and wekan-ferretdb-url (the connection URL for the external
backend). ferretdb-control now branches on the handler: for a non-sqlite handler it
execs FerretDB with --handler=<engine> --<engine>-url=<url> (the fork's binary already
exposes --postgresql-url / --mysql-url / --hana-url) and SKIPS every SQLite-file step
(rotating backup, restore, reset-oplog, corruption pre-open repair), which apply only to
the embedded SQLite file. The same wekan-ferretdb-oplog gate applies: the replica set /
OpLog is created only when opted in, otherwise standalone (polling) — and because the
OpLog/reactivity machinery is backend-agnostic, Meteor tails the OpLog on the external
backend when enabled.
snap set wekan wekan-ferretdb-handler=postgresql \
wekan-ferretdb-url="postgres://user:pass@HOST:5432/ferretdb"
Backend query correctness/performance still needs the FerretDB integration suite against
the live engine (see FerretDB ROADMAP.md).
Thanks to xet7 !
Reported: after `snap set wekan root-url="https://..."`, `snap run wekan.problems`
still showed "ROOT_URL is not set". Cause: the wrapper exec'd wekan-problems.mjs
WITHOUT the snap settings in its environment, so `process.env.ROOT_URL` (and
LDAP_ENABLE) were empty in that process and the login-page checks always reported
ROOT_URL unset — regardless of the snap setting. The DB-backed checks (broken cards,
migrations/repairs in progress) were correct; only the env-derived ones were wrong.
Source `$SNAP/bin/wekan-read-settings` (echo suppressed) before exec so ROOT_URL /
LDAP_ENABLE / DATABASE etc. are exported and the login-page checks see the same
configuration WeKan runs with.
Thanks to xet7 !
Follow-up to the #6508 import fixes: in the board view, clicking an imported
(placeholder) board member's avatar showed no "Remap User" action. The board member
popup gates it on isImportedMember(), which checks `authenticationMethod ===
'imported'` — but the board composite published board members' user docs with only
username / profile.fullname / avatarUrl / initials, WITHOUT authenticationMethod
(user-miniprofile, which publishes safeFields incl. authenticationMethod, is only
subscribed on the import screen). So the field was undefined on the client and the
action never appeared.
Publish authenticationMethod with the board members' user fields (it is already in
Users.safeFields, so this is consistent and not newly-exposed). The in-board "Remap
User" -> mapImportedBoardMember flow now works for imported board members.
Test: tests/importVirtualMembers.test.cjs guards the field is published.
Thanks to AmigaAbattoir and xet7 !
Fixes#6508,
The board card list is a Blaze {{#each}} over a LIMITED, ordered reactive cursor
sorted by `{ sort: 1 }`, which has TIES. When several cards share the same `sort`
value (or the same due date, etc.), their order is non-deterministic across
observe/poll cycles, so Meteor's diffQueryOrderedChanges computes an out-of-range
index and Blaze throws `Bad index in range.removeMember: 0`. That aborts the #each,
so the board renders NO cards (and cascades into the `undefined.remove()` teardown
error). An index-backed board card query (a recent fix) can change the tie order and
expose this.
New pure, tested helper models/lib/cardSortTiebreaker.js appends a UNIQUE `_id` key
as the final sort key (object and Meteor array forms; idempotent), making the total
order deterministic so the ordered diff is always well-defined. Applied in
client/components/lists/listBody.js (cardsWithLimit — the crashing #each, before both
the window subscription and the client cursor) and server/publications/cardsWindow.js
(the published limited window, so "first N cards" is stable between polls).
Test: tests/cardSortTiebreaker.test.cjs. Likely also resolves the same
range.removeMember "no cards" reports on other backends.
Thanks to mueschel and xet7 !
Fixes#6511,
The example config is correct, but a common mistake is proxying WeKan with
`proxy_set_header Connection "";` (or omitting the `map $http_upgrade
$connection_upgrade` / `proxy_http_version 1.1`), which stops the SockJS WebSocket
upgrade and surfaces as `WebSocket connection to 'wss://HOST/sockjs/.../websocket'
failed`. Add a Troubleshooting section explaining the symptom and the exact three
lines (and the http-context map) needed on every proxy hop.
Thanks to akshat-goel and xet7 !
Fixes#6510,
The login-page checks used affirmative titles ("ROOT_URL is set", "A migration or
repair is in progress"), so a FAILING one printed e.g. "[error] ROOT_URL is set:
ROOT_URL is not set" — confusing. Use neutral subjects ("ROOT_URL", "Migration or
repair") so the "[severity] <title>: <detail>" line reads correctly in every state.
Thanks to xet7 !
The comment-only feed (showActivities off) selected activities with
`$and: [{activityType:'addComment'}, {boardId/cardId: {$in}}]`. FerretDB v1 (SQLite)
does not push down a top-level $and, so the activities collection was full-scanned on
every poll — slow history on a big board. The two keys are distinct, so merging them
into one top-level object is exactly equivalent and lets both push down to the index
(same fix as the 10.22 card-window flatten).
Thanks to xet7 !
A) Import "map members": clicking a searched user threw
`TypeError: Cannot read properties of undefined (reading '_id')` at
`click .js-select-import`. The handler read `Template.currentData()._id`, which is
undefined when the click lands on a CHILD of the anchor (the avatar or the name
span). Read the WeKan user id from the anchor's `data-id` (event.currentTarget)
instead, and guard it — robust regardless of which inner node was clicked.
B) Admin Panel / People: saving an IMPORTED (placeholder) user as an active person
with an email threw `TypeError: Cannot read properties of undefined (reading '0')`.
The profile submit handler read `user.emails[0].verified` (and `.address`), but an
imported placeholder user (and some SSO users) have no `emails` array at all. Read
the primary email defensively (missing OR empty array) via a `primaryEmail` guard.
Tests: tests/importMapUserFixes.test.cjs; tests/importMemberMapping.test.cjs updated
for the data-id mapping.
Thanks to AmigaAbattoir and xet7 !
Fixes#6508,
The rebase rewrote eb80ee69f -> 0e0391f6c (#6506) and 00ef255b0 -> 72768e05f (#6507);
the old hashes were pre-rebase orphans that were never pushed, so their CHANGELOG
links would 404 on GitHub. Updated to the current on-branch hashes.
Thanks to xet7 !
On a fresh install (no Settings document yet, and Meteor.user() briefly null right
after the first admin logs in) the Admin panel would not open, the title bar
sometimes failed to load or showed "You are not authorized to view this page", and
the console looped `Uncaught (in promise) TypeError: Cannot read properties of
undefined (reading 'remove')` through a Tracker computation.
Root cause: ReactiveCacheClient.getCurrentSetting() and getCurrentUser() guarded
their DataCache with `!this.__x || !this.__x.get()`. Every other getter creates its
DataCache ONCE (`if (!this.__x)`), but these two ALSO rebuilt it whenever the cached
value was FALSY — so while the setting/user was absent (a fresh install, or any
transient null) a brand-new DataCache, and a brand-new Tracker.autorun, was
constructed on EVERY reactive read. That continuous create/teardown churned
computations across every app-wide template (header, admin gates) and raced Blaze's
view teardown, producing the infinite reactive loop and the removed-DomRange crash
(the same WebKit Blaze class the getBoard staleWhileRevalidate comment guards).
Fixed by creating the DataCache once, keyed on `!this.__currentSetting` /
`!this.__currentUser` only, like every other getter; the autorun already updates
reactively when the Settings document / user appears, so no rebuild is ever needed.
Returning a stable null until they exist is correct and loop-free.
Test: tests/reactiveCacheCurrentGetters.test.cjs.
Thanks to AmigaAbattoir and xet7 !
Fixes#6507,
Every board card query used `{ boardId: { $in: [board._id, board.subtasksDefaultBoardId] } }`,
and subtasksDefaultBoardId defaults to null. On FerretDB v1 (SQLite) a $in that
contains a non-string element (the null) does not push down at all, so the WHERE was
dropped and the whole cards collection was full-scanned + sjson-decoded on every
poll-and-diff cycle, across ~7 card cursors per board open. Lists and swimlanes use a
plain boardId equality (index-backed) and stayed fast — so on a big board the columns
appeared but the cards never did.
New helper models/lib/boardCardScope.js builds the scope WITHOUT null and prefers a
plain equality (index seek) when only the board itself is in scope, else an
all-string $in (which pushes down). Applied to every card-scope site in
server/publications/boards.js (8x), cardsWindow.js and cards.js.
Also flatten the lazy card-window selector (cardsWindow.js): the window was
`{ $and: [clientSelector, { boardId, archived }] }`, and FerretDB does not push down
a top-level $and, so boardId/archived were full-scanned too. Merge the board scope at
the top level (exactly equivalent when the client selector has no boardId/archived
key, which it does not — it is a per-list listId + swimlane selector; a collision
guard keeps $and otherwise), so boardId/archived push down.
The FerretDB fork side is hardened separately so a mixed $in (incl. null) also uses
the index. Test: tests/boardCardScope.test.cjs.
Thanks to xet7 !
Regression from c0a1a2784 (v10.12): it dropped `importMapMembers` from the import
wizard's `steps` array and hardcoded an empty membersMapping in finishImport, so the
map-users screen never rendered and every imported card/member/comment was assigned
to the importing user even when the person existed in WeKan.
Client (client/components/import/import.js):
- restore `steps = ['importTextarea', 'importMapMembers']` so the (auto-suggesting)
map-members step shows again;
- finishImport builds membersMapping from the members the user mapped
(member.wekanId), instead of sending `{}`. The step stays OPTIONAL — the Skip
button and the textarea "import without mapping" button still bypass it.
Server — unmapped members become virtual users instead of collapsing onto the importer:
- models/trelloCreator.js: new createPlaceholderUsers(board), run in create() before
the board is built, so it covers BOTH the Trello JSON import and the Trello API
(all-boards background) import. For each member not already mapped it maps to an
existing WeKan user by username / recorded importUsername, else inserts an inert
virtual user (loginDisabled, isActive:false, authenticationMethod:'imported')
reusing the Trello member id, so board membership and authorship keep the original
person;
- models/wekanCreator.js: createPlaceholderUsers no longer overwrites an explicit UI
mapping (skip members already in this.members) so a member mapped to a real account
is not clobbered by the identity placeholder.
A board admin can still map a virtual member to a real user later from the sidebar
(that feature is unchanged). Tests updated: tests/importVirtualMembers.test.cjs and
tests/importMemberMapping.test.cjs.
Thanks to AmigaAbattoir and xet7 !
Fixes#6506,
v10.22 was cut while these fixes were in flight, so the CRITICAL entries go in a
fresh Upcoming section above it.
Thanks to koyokr, GitHub CodeQL and xet7 !
stripExploitPatterns() looped a CHAIN of six replaces to a fixpoint. That is
runtime-safe, but CodeQL (correctly, as a local check) could not attribute the
fixpoint to the individual `<[^>]*>?` tag replace, so it kept flagging it as an
incomplete sanitizer that "may still contain <script".
Restructure to the proven-complete pattern already used by
client/lib/importDependencies.js stripHtml() (which cleared the sibling alert
#421): remove template/PI/CDATA tokens (looped), then strip HTML/XML tags with a
SINGLE `replace(/<[^>]*>/g, '')` looped to a fixed point, then drop any stray
angle bracket so an UNCLOSED tag (no '>', e.g. a trailing "<script") cannot
survive either. Behaviour is unchanged for every existing case.
Regression: tests/fileNameDisplay.test.cjs now asserts completeness for closed,
unclosed and spliced tags (no '<', '>' or '<script' in the output).
Thanks to xet7 !
A board member could store entity-encoded markup in a card title. It stays inert
on the live board (Blaze escapes it; the +viewer sanitizer neutralizes handlers
and keeps the entity payload as text), but the exported index.html embedded a
click handler that read the card title/body via .textContent — which DECODES HTML
entities — and then concatenated those values into content.innerHTML. That SECOND
parse revived the tag (e.g. `<img src=x onerror=...>`) and executed it when a
recipient clicked the card in the export, disclosing all data in that document
(including cards added after the attacker's board membership was removed).
The modal is now built with DOM nodes and the card title/body are assigned through
textContent, never innerHTML, so they are inserted as inert text.
Regression: tests/exportHTMLXss.test.cjs (title/body reach only textContent; no
titleText/allText flows into any innerHTML; a textContent assignment does not
revive an entity-decoded <img>).
(CWE-79 stored XSS, GitHub Security Advisory GHSA-8r5p-4q9j-f5jx.)
Thanks to koyokr and xet7 !
The 10.16-10.21 reports of the ferretdb process pegging ~2 cores for a long time
while node sat idle are the signature of an OpLog tail: Meteor holds a tailable
cursor on local.oplog.rs and FerretDB re-scans it server-side. wekan-control
already defaults to polling-only (it clears MONGO_OPLOG_URL), but ferretdb-control
passed --repl-set-name unconditionally, so FerretDB ALWAYS maintained the capped
OpLog (a second write per mutation, a once-a-minute cleanup, and a tailable cursor
for any stray MONGO_OPLOG_URL to spin on) even when WeKan would not tail it.
Gate --repl-set-name on WEKAN_FERRETDB_OPLOG (default false), matching
wekan-control: in the default polling-only mode FerretDB now runs STANDALONE, with
no OpLog at all; the replica set / OpLog is created only when the admin opts in with
wekan-ferretdb-oplog=true. Opting in is now also cheaper on the FerretDB fork side
(the {ts: {$gt}} tail filter is pushed down and the OpLog Timestamp indexed).
Docs: docs/Features/Admin-Panel/Problems/Migrations.md (FerretDB reactivity mode).
Test: tests/ferretdbOplogGating.test.cjs.
Thanks to xet7 !
The reporter confirms OIDC works again after updating to WeKan 10.21. The two
source parts (the raw i18n key `changeLanguagePopup-title` and the `oplog catching
up took too long` stalls) were fixed in v10.16+; the remaining dead OIDC/Register
buttons were a stale dynamic-import bundle cache on the snap after the refresh
(no source regression), which a clean >=10.16 build clears. Removed from the
TODO Later backlog.
Thanks to Alishara and xet7 !
Closes#6503,
The rebase onto origin/main rewrote the local commit hashes, so the Upcoming
section's commit links pointed at pre-rebase hashes that never reached the remote.
Update all six to the pushed hashes (doubled-cards, repairBoardWideLists, board-open
auto-detect, shared board data-repairs, #6504 card-move fix, Problems Status /
snap wekan.problems).
Thanks to xet7 !
docs/Features/Admin-Panel/Problems/README.md describes what Problems offers and
links the detailed pages (existing CPU/RAM/Disk/Recovery plus the new Repairs,
Migrations, Login-Problems and Snap pages). Snap.md documents `snap run
wekan.problems` and its sub-commands (migrations | login | broken-cards | cpu).
Repairs.md / Migrations.md cover the shared board data-repairs and the MongoDB <->
SQLite migration, when they run (board open, server startup, during migration) and
the progress dashboard. Login-Problems.md explains the "Must be logged in" /
"Loading, please wait" causes and fixes, tying them to a saturated ferretdb.
Thanks to xet7 !
Motivated by the 10.16-10.21 reports where, after an upgrade, the login page
showed "Must be logged in" or sat on the logo + "Loading, please wait." spinner,
pages took 5+ minutes, All Boards counts stayed 0 and i18n showed raw keys — the
FerretDB v1 (SQLite) process pegged ~2 cores for a long time under WeKan's poll
load, i.e. a migration/repair or a saturated backend, with no way to see it
without the Admin Panel.
Server-side, independent of any client / progress page:
- server/startup/repairBoardsOnStartup.js runs the shared board data-repairs once
(version-gated, background, 30s after boot) so corrupted data is fixed even if
no user opens a board and nobody watches a progress page.
- The MongoDB <-> SQLite text migration and the startup repair now PERSIST their
progress to the text_migration_status collection (models/textMigrationStatus.js),
so a separate process can see "a migration/repair is in progress" (an in-memory
object could not).
Status overview (server/lib/systemStatus.js), shown in Admin Panel / Problems ->
Summary and via the method systemStatusReport (admin-gated, server/methods/
systemStatus.js):
- everything in progress (text migration, board repair, recovery, cron migration,
attachment migration) aggregated from the persisted status collections;
- detected problems (broken cards; failing login-page checks);
- login-page "Must be logged in" / "Loading, please wait" cause checklist
(migration in progress, ROOT_URL, LDAP, Sandstorm) — models/lib/loginProblems.js;
- a CPU detail area that calls out a pegged ferretdb process and the mitigation.
Snap: `snap run wekan.problems` (snap-src/bin/wekan-problems[.mjs], snapcraft app
`problems`) prints the same overview as text — problems, migrations/repairs in
progress, login checks — so an admin with only server access can see it WITHOUT
Admin Panel access. Sub-commands: migrations | login | broken-cards | cpu | help.
Pure helpers models/lib/loginProblems.js and models/lib/problemsOverview.js are
unit-tested; tests/problemsStatus.test.cjs (14 checks) also source-guards the
server hub, method, startup pass, migration persistence and snap command.
Thanks to xet7 !
On the server ReactiveCache.getBoard() is async (returns a Promise). The
cross-board branch of Cards.helpers.move() called it without await, so `newBoard`
was a Promise: `newBoard.getNextCardNumber()` threw, and `oldBoard` being a
Promise silently dropped label carry-over. Await both getBoard() calls (same fix
as PR #6505).
Added tests/cardMoveAwaitBoard.test.cjs as a regression guard.
Thanks to ChristianMa97 and xet7 !
Closes#6505,
Fixes#6504,
The board-open self-heal is broadened from the #6484 list-unbind alone to a
shared repair set (models/lib/boardRepair.js planner + server/lib/repairBoardData.js):
- #6484: lists wrongly bound to a swimlane -> cleared back to board-wide, so the
list stops "disappearing" from the other swimlanes;
- cards with no swimlaneId (null/''/missing), which never render in the Swimlanes
view -> assigned to the board's first swimlane;
- orphaned cards whose swimlaneId points at a DELETED swimlane (invisible cards)
-> reassigned to the first swimlane. A card on an existing but archived swimlane
is NOT treated as orphaned.
The same repair set now runs in BOTH places:
- Board open: boardBody.js maybeRepairBoard -> boardRepairNeeded / repairBoardData
(server/methods/repairBoardData.js), once per board, admin-gated, fire-and-forget.
- MongoDB <-> FerretDB v1 (SQLite) text migration: migrateTextDatabase runs
repairAllBoards() on the live database BEFORE copying, so the migrated copy is
clean too. It reports a new "repairing" phase (boardsDone/boardsTotal/repaired).
Both flows drive ONE shared progress dashboard (migrationProgress), now:
- mounted app-wide (defaultLayout) so it shows for an Admin Panel database
migration as well as a board-open repair;
- fed from the DB-migration status poll (attachments.js driveMigrationDashboard);
- styled in WeKan blue (#2980b9) instead of the old purple/green;
- branded with the configured Product name (from the earlier commit).
Tests: tests/boardRepair.test.cjs (planner + server/migration/dashboard source
guards, 11 checks) and the updated tests/listUnbindRepair.test.cjs pass.
Thanks to xet7 !
When a board opens it now checks (boardListRepairNeeded) whether any list is
wrongly bound to a single swimlane (the #6484 corruption, which makes a list
vanish from the other swimlanes). If so, and the viewer is a board admin, it
runs repairBoardWideLists automatically while showing the shared
migration-progress modal, then completes. The check runs once per board,
fire-and-forget, and never blocks rendering; on error the board is unmarked so a
later open retries.
The migration-progress modal is now branded with the configured Product name
(Admin Panel / Settings / Layout / Product name, Settings.productName), falling
back to WeKan when none is set, via the pure models/lib/productName.js helper —
so the repair (and every migration reusing this modal) shows the admin's Product
name instead of the hard-coded WeKan brand.
Tests: tests/productName.test.cjs (helper + modal-branding source guards) and
the extended tests/listUnbindRepair.test.cjs (detection method + client
detect/repair/progress wiring) pass.
Thanks to xet7 !
The #6484 bug (nudging a board-wide list in swimlanes view bound it to one swimlane and moved its cards there, so it vanished from the other swimlanes) is fixed in code, but boards already hit keep the wrongly-set list.swimlaneId. New board-admin-gated method repairBoardWideLists(boardId) clears swimlaneId back to null for every swimlane-bound list on that board, restoring them to board-wide (rendered under every swimlane). Idempotent (lists already board-wide are skipped), scoped to the one board, and returns the count repaired. The list-selection is a pure, unit-tested models/lib/listUnbindRepair.js. Note: this repairs the LIST binding only; cards the bug moved into one swimlane are not restored (their intended swimlane is unknown -- recover those from a backup).
Tests: tests/listUnbindRepair.test.cjs (5 checks) covers listsToUnbind (selects bound lists, idempotent, invalid inputs, non-string swimlaneId) and a source guard that the method is board-admin-gated, uses the helper, clears swimlaneId to null, and is scoped to the board.
Thanks to xet7.
In swimlanes view a card with swimlaneId null/'' (a 'shared' / pre-migration card) was surfaced in EVERY swimlane: swimlaneMembershipSelector used { swimlaneId: { $in: [swimlaneId, null, ''] } } for non-first swimlanes, and filterCardsByListAndSwimlane matched null/''/missing there too. On a board with several swimlanes the same shared card therefore rendered once per swimlane -- the reported 'doubled cards/entries', which also bloats the DOM (contributing to the search hang / can't-scroll on big boards). A non-first swimlane now matches ONLY its own cards ({ swimlaneId }); shared and orphaned cards surface ONCE, in the FIRST swimlane (the $nin branch, unchanged), so a card is never shown in more than one swimlane. Still a single field clause, so the #6441 board-wide label-filter fix is preserved (verified in the tests).
Tests: tests/swimlaneFilter.test.cjs updated -- a non-first swimlane matches only its own cards; shared/orphaned cards appear once in the first swimlane and are still filtered by the active label filter; #6441 board-wide filtering for cards that HAVE a swimlaneId is unchanged. 18 checks pass.
Thanks to xet7.
Note that #6503 is partly fixed in v10.16+ (the raw i18n key via static-bundled English + timeout-bounded init, and the 'oplog catching up' stalls via the FerretDB polling-only default), while the remaining dead OIDC/Register buttons are not a source regression (login code identical 10.11->10.13) but a stale dynamic-import bundle cache on the snap, needing the reporter to confirm on a clean >=10.16 install with cleared cache, plus a browser console/Network capture if it persists.
Thanks to Alishara and xet7.
Add a 'Deferred pending a security decision' bucket for syntax/color highlighting of code blocks in the card +viewer (also asked in #5149): it is possible via MarkdownIt's highlight option + a highlighter like highlight.js, but the viewer's DOMPurify strips every class/id attribute for CSS-injection safety, so a highlighter's <span class=hljs-...> output would lose its classes and show no colour. Enabling it needs a tight allowlist of hljs-*/language-* classes on spans inside pre>code, a sanitizer relaxation xet7 has not decided on yet.
Thanks to xet7.
The copy-code-block feature existed but the reporter saw it 'work very sporadically (only a handful of items have it)' and lost after editing. Root causes: it ran ONCE in Template.editor.onRendered with a global document.querySelectorAll('.viewer > pre'), so it decorated only whichever viewers were on the page at that instant and never re-added the button after an edit re-rendered the viewer; and it copied the HTML-escaped innerHTML of the <pre>'s first child node (often the wrong content or undefined) via the deprecated execCommand. Now the decoration lives in Template.viewer.onRendered, so EVERY viewer (card description, checklist item, comment) gets a copy button and it is restored on every re-render; it is de-duplicated (skips a <pre> that already has its button) so re-renders never stack buttons; it copies the RAW code text (pre.textContent) via navigator.clipboard.writeText with an execCommand fallback; and the button title is translated (the existing 'copy-text-to-clipboard' i18n key) instead of a hard-coded English string.
Tests: tests/copyCodeBlock.test.cjs (5 checks) guards that the decoration is in Template.viewer.onRendered scoped to the viewer's <pre>, copies textContent (not innerHTML), de-dups, is translated, and uses the async Clipboard API with a fallback.
Thanks to C0rn3j and xet7 !
Fixes#5149,
A card URL is /b/:boardId/:slug/:cardId; after the card was moved to another board the link opened the OLD board and found nothing. The card route now resolves the card via the permission-checked 'card' publication (server/publications/cards.js, which only returns the card when the user may see its board) and, if the card's CURRENT board differs from the URL's board, redirects to /b/<currentBoard>/<slug>/<cardId> so the card opens where it now lives -- so a link stays valid across board moves as long as the viewer has access to the destination board (like Trello). When the user cannot see the card's new board (or it is gone) the probe subscription yields nothing and the URL's board is kept, and the redirect is guarded against a redirect loop (target board matches -> stop) and against firing after the user navigated away. The decision is a pure, unit-tested models/lib/cardLinkRedirect.js. (A toast telling the user 'this card was moved to a board you cannot access' in the no-access case is a possible follow-up.)
Tests: tests/cardLinkRedirect.test.cjs (6 checks) covers the moved-card redirect, the same-board no-op, missing/invalid card (stay put), the no-loop invariant, and a router source guard that it drives off the permission-checked 'card' publication.
Thanks to Robdebert and xet7 !
Fixes#4758,
#4043 ('Sometimes user get board invitation by mail without invitation code' — recipients got an email whose code the sign-up form rejected with 'The invitation code doesn't exist') is already fixed and shipped: the pure models/lib/invitationCodeEmail.js rules (normalizeInviteEmail lowercases the stored email so it matches the sign-up form, isInvitationCodeSendable refuses to mail a missing/invalid code, buildReinviteModifier overwrites a stale code with a fresh valid one on re-invite, and shouldRemoveInvitationOnEmailFailure only rolls back a code created by this very invite) are wired into server/models/settings.js sendInvitation and covered by tests/invitationCodeEmail.test.cjs (14 checks, incl. the settings.js wiring). It was mis-filed under 'Feature requests' in the CHANGELOG TODO Later; removed from there.
Thanks to Emile840 and xet7 !
Fixes#4043,
#6430 (~1s card flicker dragging on large boards — a drag/reactivity re-render; xet7 already reduced it in 2e7c4ed but it persists, needs a large board + browser to profile) under 'need the running app'; #5323 (due-date notification/webhook with per-board offset — the built-in NOTIFY_DUE reminder already exists and was improved in #3192, so the remainder is a feature) under 'feature requests'.
Thanks to xet7.
Explain what the '# TODO Later' section at the top of CHANGELOG.md is for (open issues investigated but not fixed here, each with a concrete reason), how it fits the 'Fix open issues' process (fix / close-if-already-fixed / else add to TODO Later with the reason), the category buckets (need infra/running-server, need the running app to reproduce, already-correct, feature/by-design, needs a maintainer decision), that entries use issue links (not commit links) since nothing was committed, and that fixed issues must be REMOVED from the list once their Fixes #NNNN commit closes them.
Thanks to xet7.
Continue triaging open issues that cannot be fixed/verified in this sandbox: #1942 (blank/frozen view opening a linked card the viewer has no rights to — runtime permission + reactive close), #1995 (edit fields on a linked card — feature/by-design, same class as #3748), #3001 (manipulated headers behind an Apache reverse proxy — a proxy-config concern needing the reporter's setup). #1972 and #2306 already carry Fixes commits and close on push.
Thanks to xet7.
#1158 (on a public read-only board an anonymous / not-logged-in user could still DRAG lists, which made mobile scrolling almost impossible even though the reorder was denied server-side) is already fixed by #5462: all three list sortables in client/components/swimlanes/swimlanes.js set disabled: !Utils.canModifyBoard(), and canModifyBoard() requires a current user who is an active, non-comment-only, non-read-only board member -- so an anonymous user (no currentUser) can never drag lists. Covered by the Playwright spec 35-list-sort-permissions.e2e.js; this adds a plain-node source-guard so the invariant (every list sortable gated by canModifyBoard, which is falsy for anonymous) cannot silently regress.
Thanks to GenericUK and xet7 !
Fixes#1158,
Remove entries that have since been fixed (they carry Fixes #NNNN and close on push): #4560/#4419/#4158 (LDAP, startup-upgrade batch), #4825/#4897, #4822, #3826, #5282/#5547, #3453/#3199/#3843, #4593 and #3037 — with a short note in the intro pointing at them. Add newly-triaged still-open issues with the reason each is not fixed here: #1094/#2445 (need a running server stack / environment), #1658/#1946/#5052/#5421/#761 (need the running app to reproduce/verify), and #5081/#1213 (feature/design proposals). Drops the now-empty 'LDAP security/config' and 'Incomplete report' buckets.
Thanks to xet7.
#3037 (moving a card between boards via the API bounced back to the old board when only the raw boardId/listId were edited) is already fixed: the edit-card handler (server/models/cards.js) normalizes newBoardId/newSwimlaneId/newListId via normalizeMoveParams, and when all three are present (isBoardMove) it validates the destination list+swimlane belong to the destination board and re-homes the card through cardMove(..., ['boardId','swimlaneId','listId'], ...) instead of a raw field update (Issue #5398/#5399). The pure helpers had only Playwright coverage; this adds a plain-node unit test (dynamic import of the ES helper) covering normalizeMoveParams (all-three => board move, a PARTIAL set is NOT a board move so a card is never half-moved, same-board move, empty/empty-string negatives) and computeTopSort, plus a source guard that the handler re-homes through cardMove. The supported API is newBoardId/newSwimlaneId/newListId (not a raw boardId edit).
Thanks to rptl and xet7 !
Fixes#3037,
#4737/#5850: the per-org/team orgPropagateMembersToBoards / teamPropagateMembersToBoards flag was stored and shown in the Admin Panel, but the propagateOrgTeamMembersToBoards method that acts on it had NO caller anywhere — dead code, so turning the flag on did nothing. The propagation logic is refactored into exported propagateGroupMembersToBoards(kind, groupId) / propagateAllFlaggedGroupsToBoards() (the Meteor method now delegates to the latter), and the flag setters setTeamPropagateMembersToBoards / setOrgPropagateMembersToBoards now run the propagation for that group when the flag is turned ON. Still strictly add-only (existing board members are never removed/modified) and template boards are skipped; the add-only member computation is extracted to a pure, unit-tested models/lib/propagateMembers.js.
Tests: tests/propagateMembers.test.cjs (9 checks) covers membersToAddToBoard (add-only, de-dup, already-member, invalid inputs) and source guards that both flag-setters propagate on enable, the method delegates to the shared impl, and it stays add-only + board-type-only.
Thanks to xet7 !
#4593 (a user added to a team AFTER it was assigned to a board never gained membership/authority on that board) is already fixed: server/models/users.js addUserToTeamBoards uses the pure, tested models/lib/teamBoardMemberSync.js decision logic, and is called from BOTH editUser (the admin People-panel path in the reproduction) and the create-user-with-teams path, so a late-joining team member is pushed into board.members like the team's original members. The pure helper was covered by tests/teamBoardMemberSync.test.cjs; this adds source-guard tests that the two server call sites actually invoke it (and that it routes through the helper), so the fix cannot silently regress and reopen#4593.
Thanks to mianbaoshumoon and xet7 !
Fixes#4593,
The add-card form's Tab handler (Template.addCardForm pressKey, keyCode === 9) is a deliberate power feature -- Tab jumps to the NEXT column's add-card form so cards can be added across columns quickly. But it opened that next form while abandoning whatever was typed in the current one, so pressing Tab mid-entry silently lost the card text (the card appeared to 'move to the next column' with no content). It now submits the current card first, but only when the textarea has non-whitespace content (so Tab in an empty box does not create a blank card), then jumps to the next column's form -- preserving both the content and the column-jump feature.
Tests: tests/addCardTabSubmit.test.cjs (4 checks) guards the ordering -- the Tab branch reads the textarea, submits on non-empty content BEFORE openForm of the next list, still opens the next column, and does not submit for an empty box.
Thanks to callahad and xet7 !
Fixes#1195,
Convert the Upcoming (#3192) and v10.14/v10.15/v10.16 bug-fix bullets I added from '[#NNNN](issues/NNNN)' to the CLAUDE.md format '[description (#NNNN)](commit-url). Thanks to X and xet7.' -- #3192 (c0bbacaf9), FerretDB polling-only #6503 (b15d89dd0), i18n raw-key #6503 (eb411d9a5), rules remove-all-members #2674 (e1ebe978b), archived-swimlane #1971/#1959 (52bb15594), @member autocomplete (2328bcd0f), #label autocomplete (728cd929c). The CRITICAL/Bleed security entries keep their hall-of-fame links and the Dependabot entries keep their CVE/advisory links, as those are the correct references.
Thanks to xet7.
Detail how to extend WEKAN_REPO_TOKEN to the two variant repos for each token type: a classic 'repo' PAT usually needs nothing changed (just org write access), a fine-grained PAT must add wekan-ondra/wekan-gantt-gpl with Contents: Read/Write, or use per-repo deploy keys -- the stored secret value never changes either way (no gh secret set step), with a throwaway-push verify command. Also correct the now-stale status note: the snap-variants job is currently hard-disabled with 'if: ${{ false }}' (grouped with the failing snap exotic-arch jobs), so publishing variants now needs BOTH steps 1-4 AND removing that 'if' line (new step 5), and update the checklist to match.
Thanks to xet7.
The snap builds for the exotic arches fail, so skip them on release: snap-qemu (ppc64el, s390x snaps), snap-launchpad (riscv64 snap), snap-variants, nextcloud and ucs each get 'if: ${{ false }}' (re-enable by removing that line). build-extra-arches is kept ENABLED: it builds the wekan-<version>-{ppc64le,s390x,riscv64}.zip bundles that the docker job bakes into the full multi-arch image (amd64, arm64, ppc64le, s390x, riscv64) -- that path works, only the snap exotic-arch builds fail.
Thanks to xet7.
Two source bugs kept due-date reminder mail from reaching people. (1) The reminder hour was parsed as parseInt(NOTIFY_DUE_AT_HOUR_OF_DAY, 10) || 8, so a configured hour of 0 (midnight) silently became 8 (0 is falsy) and out-of-range hours were accepted; parseNotifyDueHour now keeps 0 and rejects anything outside 0..23. (2) A due-card activity's notification participants were only the card CREATOR and its MEMBERS (server/models/activities.js) -- a user ASSIGNED a card but not a member was never notified about it, including its due date; card.assignees are now included too (still gated downstream by the board tracking level, so nobody who is not tracking is newly emailed). The NOTIFY_DUE_* parsing is extracted to a pure, unit-tested models/lib/dueNotificationConfig.js. Note: the built-in reminder still requires NOTIFY_DUE_DAYS_BEFORE_AND_AFTER to be set, and members/assignees are emailed per their board watch/tracking level.
Tests: tests/dueNotificationConfig.test.cjs (12 checks) covers the midnight-hour case, valid/invalid/out-of-range hours, the day-offset window parsing and negatives, plus source guards that cards.js uses parseNotifyDueHour and that assignees are in the notification participants.
Thanks to SirConfigMgr and xet7 !
Fixes#3192,
ferretdbOplogReset.test.cjs forbade any rm touching 'wekan.sqlite', but ferretdb-control legitimately removes the transient wekan.sqlite-wal/-shm sidecars before copying a backup over the data file. The guard now forbids only the bare data file / glob (via a (?!-) lookahead) and allows the -wal/-shm/-journal sidecars. Pre-existing test failure, source is correct.
Thanks to xet7.
FerretDB v1 can tail an OpLog, but on the SQLite backend Meteor's tailable+awaitData OpLog tail keeps FerretDB CPU pinned (reporters saw ~190-390% even idle; a 2-core box maxed out) and a struggling tail also surfaces as 'oplog catching up took too long', stalling board and login-page loading. Despite the FerretDB-side mitigations (16 MiB capped oplog, 500ms awaitData poll, SQLite pragmas, CPU self-regulation) the peg persisted on real deployments, and the polling-only path reliably drops CPU to ~10%. So make POLLING the default on every launcher (snap wekan-control, bundle start-wekan.sh, docker wekan-entrypoint.sh + docker-compose.yml, windows start-wekan.bat, sandstorm start.js): WEKAN_FERRETDB_OPLOG now defaults false, docker-compose reactivity is 'polling' with MONGO_OPLOG_URL commented out. The OpLog machinery still exists and is opt-in via WEKAN_FERRETDB_OPLOG=true. The snap exposes it as a setting: 'snap set wekan wekan-ferretdb-oplog=true|false' (registered in snap-src/bin/config, default false). The calmer polling throttle (#6467/#6468) and SQLite pragma tuning keep poll-and-diff cheap.
Tests: tests/ferretdbOplog.test.cjs updated to assert the polling-only default everywhere, the commented-out docker-compose MONGO_OPLOG_URL, the opt-in OpLog machinery still present, and the new wekan-ferretdb-oplog snap setting (default false).
Thanks to xet7 !
TAPi18n.init() awaited a dynamic import('./data/en.i18n.json') and only set TAPi18n.ready=true afterwards. If that dynamic chunk hung or rejected -- e.g. a stale snap client bundle after a refresh, the reported #6503 scenario -- ready stayed false forever and the '_' Blaze helper returned every key raw (the untranslated changeLanguagePopup-title), with no recovery. Two guards: (1) the default English is now STATICALLY bundled (import enData from './data/en.i18n.json') and registered first, so the UI is always readable even when dynamic import() is broken; every other language still loads lazily. (2) the normal loadLanguage('en') (which also layers custom DB translations) is bounded by a 10s timeout and its failure is swallowed, so ready.set(true) is reached in EVERY path. index.js also guards the startup so init can never leave an unhandled rejection. The ES-module-namespace unwrap and the timeout guard are extracted to a pure, unit-tested imports/i18n/loadHelpers.js and shared with loadLanguage().
Tests: tests/i18nLoadHelpers.test.cjs (10 checks) covers unwrapI18nModule (real namespace vs the #5756 literal-"default"-key trap, null/plain) and promiseWithTimeout (resolves/rejects in time, and REJECTS instead of hanging when the promise never settles), plus a source guard that init sets ready in every path. Note: this hardens the i18n (raw-key) symptom and makes it recoverable; the dead OIDC/Register buttons need in-browser confirmation of the stale dynamic-import cache (see issue notes).
Thanks to Alishara and xet7 !
The rule member actions operate on a card's ASSIGNEES: addMember calls card.assignMember() and removeMember calls card.unassignMember() (both write card.assignees). The 'remove all' branch (username === '*') however iterated card.members -- a different collection -- so it unassigned nobody a rule had assigned and 'remove every member' silently did nothing. Iterate the card's assignees (card.getAssignees()) instead, snapshotting the ids first since unassignMember pulls from that same array. The single-user add/remove were already symmetric (the earlier #2674 fix that made them assign/unassign); this completes it for the wildcard case.
Tests: tests/ruleRemoveMemberAction.test.cjs (6 checks) pins the add/remove symmetry, that the '*' branch reads assignees (not card.members) and still unassigns each, and the defensive skip for an unresolved username.
Thanks to sfahrenholz and xet7 !
Fixes#2674,
Same root cause as #1971, now fixed: new cards and the List-view card drop both resolve the target swimlane through Board.getDefaultSwimline() (client/components/lists/list.js), which now skips archived swimlanes (pickDefaultSwimlane) -- so a card is never assigned to a deleted/archived 'General' swimlane and made invisible in Swimlane view. Cards already orphaned by an earlier swimlane deletion keep surfacing in the first swimlane via the #6443 orphanedCardsSwimlaneIds fallback (covered by swimlaneFilter/ruleMoveAction tests). Adds a wiring guard tying the two together.
Thanks to hnb1 and xet7 !
Fixes#1959,
defaultBoard.test.cjs asserted boardsList.js never calls toggleDefaultBoard, but d67d27f0d re-enabled setting the Home board via the 'Selected:' bulk action (js-home-selected), which legitimately calls it. The per-tile toggle stays disabled; the test now checks that instead of forbidding the call outright. Test-only; source is correct.
Thanks to xet7.
Board.getDefaultSwimline()/getDefaultSwimlineAsync() picked the first swimlane for the board with no archived filter (ReactiveCache.getSwimlane({ boardId })), so when the first/default swimlane was archived, a card added in List view was assigned to that archived swimlane and became invisible in Swimlane view (visible only in List view until the swimlane was unarchived). Both getters now choose via a pure pickDefaultSwimlane() helper that prefers the first NON-archived swimlane, falling back to the first one only when every swimlane is archived (so callers reading ._id never crash) and returning undefined only when the board has no swimlanes at all -- the single case where the server self-heals a fresh default (#6382/#6429 idempotency preserved).
Tests: tests/defaultSwimlane.test.cjs gains pickDefaultSwimlane cases -- the reported scenario (default archived + active swimlanes -> first active), unchanged behaviour when the first is active, all-archived fallback, empty/null -> undefined, skipping null entries, and a source guard that both getters route through the helper.
Thanks to rangersdo and xet7 !
Fixes#1971,
Follow-up to the #5116 label fix: the add-card-title '@' member mention in client/components/lists/listBody.js matched with user.username.indexOf(term) === 0 -- case-sensitive, prefix-only, username-only, and it threw when ReactiveCache.getUser() returned null. So '@ann' did not suggest 'Anna', '@Anna' did not match username 'anna', and a full-name search never matched. The card description/comment editor (client/components/main/editor.js) already matched case-insensitively on username OR full name but shared no code and had the same null hazard. Both now route through a pure, unit-tested models/lib/memberAutocomplete.js (memberMatchesTerm / filterMembersByTerm) that lowercases the term and matches username or profile.fullname as a substring, and is null-safe.
Tests: tests/memberAutocompleteMatch.test.cjs (11 checks) covers case-insensitive + substring + full-name matching, empty-term-shows-all, null/undefined user (the old crash), missing profile, order preservation, and source guards that both '@' call sites use the shared matcher.
Thanks to rjl9 and xet7 !
Typing '#test' in the add-card / edit-card-title field did not suggest a label named 'Testing': the label search matched with a case-SENSITIVE label.name.indexOf(term) (and label.color.indexOf(term)), so only '#Test' matched 'Testing'. The board's '@' member autocomplete already matches case-insensitively; this brings the '#' label autocomplete in line. Extracted the match into a pure, unit-testable models/lib/labelAutocomplete.js (labelMatchesTerm / filterLabelsByTerm) that lowercases both the term and the label name/color, mirroring the other models/lib pure helpers.
Tests: tests/labelAutocompleteMatch.test.cjs covers the exact #5116 scenario (#test -> Testing), color-fallback matching, empty-term-shows-all, order preservation, and negatives (non-substring, missing name/color, null label, non-array), plus a source guard that listBody.js routes through the shared matcher. 11 checks pass.
Thanks to rjl9 and xet7 !
Fixes#5116,
Document the webpack-dev-server 5.2.6 and http-proxy-middleware 2.0.10 overrides in the Upcoming security section, why elliptic (#55) has no fix, and why the @rspack/cli 1->2 and @babel/parser 7->8 major bumps are deferred.
Thanks to GitHub Dependabot and xet7.
Resolve three Dependabot alerts in the rspack build-toolchain dev dependencies without touching the rspack major version, so builds are unaffected. Both packages enter only via @rspack/dev-server (the 'rspack serve' dev server) and are not used by 'meteor build'. webpack-dev-server 5.2.5 -> 5.2.6 fixes CVE-2026-14631 (DoS via malformed Host/Origin header, alert #113) and CVE-2026-14620 (CSRF via internal /webpack-dev-server endpoints, alert #114). http-proxy-middleware 2.0.9 -> 2.0.10 fixes CVE-2026-55602 (host+path router substring-match backend bypass, alert #107). Both are patch releases within the same major line, so the lock resolves cleanly (only those two entries change) and the rspack CLI/core stay at 1.7.11. elliptic (alert #55, CVE-2025-14505) has no fixed version published upstream (latest is still 6.6.1), so it is left pinned; the @rspack/cli 1->2 (PR #6497) and @babel/parser 7->8 (PR #6484, a runtime dependency) major bumps are deferred as they need build/runtime testing first.
Thanks to GitHub Dependabot and xet7.
CLAUDE.md gains the 'Fix open issues' process (research newest maintained dependencies via Meteor 3 docs/issues/forums, atmosphere/packosphere/npm, add tests+negative+UI tests, commit format). docs/Security/Sandboxes/vscode/README.md documents a version-matched from-scratch toolchain in .tools/ (Node v24.18.0, npm, Meteor 3.5, newest Go for FerretDB) to build the WeKan bundle + FerretDB and run all tests, and notes Docker/podman is unavailable in the Flatpak sandbox. server/00waitForMongo.js keeps the Meteor.startup wait but documents the #6500 finding: accounts-base creates the users index before app hooks, so a top-level await here deadlocks — the reliable fix is the docker-compose healthcheck.
Thanks to xet7.
ldapConnectionRelease: strip comments before the source-guard search so a comment mentioning ldap.connect() (before the guarded call) no longer trips the 'connect inside the guard' assertion. htmljsArrayContent: provide a minimal Package global before requiring the vendored htmljs.js, which reads Package.meteor/Package.tracker at load before creating Package itself. ferretdbOplog: accept the hardcoded polling launcher form as well as the ${VAR:-polling} form. Source code unchanged; these are test-harness fixes surfaced by running the suite under a clean Node install.
Thanks to xet7.
Document the two GitHub CodeQL code scanning fixes already committed (alerts #425 js/incomplete-multi-character-sanitization in imports/lib/fileNameDisplay.js and #424 js/identity-replacement in tests/securityLog.test.cjs) in a new Upcoming section above v10.13, linked to the wekan.fi Hall of Fame entries.
Thanks to GitHub CodeQL and xet7.
A menu-id regex was built with id.replace('report-', 'report-') — replacing a substring with itself, a no-op CodeQL flags because it is almost always a mistake for a real transformation. Match 'js-' + id directly instead. Resolves code scanning alert #424. Test-only, no runtime exposure.
Thanks to xet7.
stripExploitPatterns() stripped HTML/script/template markup in a single pass, so nested or interleaved fragments — e.g. <scr<x>ipt> or <scr{{y}}ipt> — could have the inner part removed and the two surviving outer fragments spliced into a fresh <script> token that the single pass no longer re-examined. Apply the removals repeatedly until the string stops changing (a fixpoint); each pass only deletes text, so the string strictly shrinks and the loop always terminates, and any dangerous token an earlier removal reveals is removed too. Resolves code scanning alert #425. Blaze {{ }} already HTML-escapes every rendered filename, so this is defence-in-depth on displayed text, but the single-pass strip was genuinely incomplete.
Thanks to xet7.
Document that 'check newest test logs' means the newest ../log/<datetime>/
directory, and that VSCode runs in the Flatpak sandbox from
docs/Security/Sandboxes/vscode/vscode-sandbox.sh (details in that README.md).
Thanks to xet7 !
pull-translations.sh ran tx pull -f (which fills untranslated strings with the
English source) and then only auto-healed files whose changes were ENTIRELY
reverts -- a file that also got a real new Transifex translation was skipped, so
its reverted strings were lost back to English. Replace that whole-file heal with
a per-KEY merge (releases/translations/merge-translations.mjs): for every language
file and key, keep Transifex's newest human translation, restore a committed human
translation the pull reverted to English (even in files that also received real
new translations), and leave only genuinely-missing keys (untranslated on Transifex
AND never committed) as the English placeholder for machine translation. So a pull
always brings the newest Transifex translations and never overwrites a human
translation with English/machine; only missing-everywhere strings are machine
translated. Restored languages are pushed back to Transifex.
Add CLAUDE.md at the repo root (read first by Claude) documenting: the translation
policy above; that direct-commit / commit-as-Lauri-Ojansivu / all release steps are
MAINTAINER ONLY (only when git identity is Lauri Ojansivu <x@xet7.org>) while other
contributors use pull requests; plus the general practices, CHANGELOG structure,
no-argument release flow and test conventions from ../log/v10/Claude.txt.
Thanks to xet7 !
On a fresh `docker compose up`, the browser got "Connection reset by peer" and
WeKan never loaded (#6500). The compose's ferretdb service downloads its binary at
first run (apt-get + curl), so it is not listening for a while after its container
starts. WeKan's depends_on used `condition: service_started`, which only waits for
the ferretdb CONTAINER to start, not for the database to accept connections -- so
WeKan started against a not-yet-ready database and failed. The comment above
depends_on already said WeKan should wait for the DB to be HEALTHY; the config just
did not implement it.
Add a healthcheck to the ferretdb service (a dependency-free bash /dev/tcp probe of
127.0.0.1:27017, healthy only once FerretDB is actually listening, with a
start_period that covers a slow first download) and change WeKan's depends_on to
`condition: service_healthy`, so WeKan starts only after FerretDB is ready.
Thanks to youhajjioui and xet7 !
Fixes#6500,
The admin Files report showed "No results" on FerretDB (spec 41 failed in every
Playwright run). Root cause, reproduced against a real FerretDB with the Go Mongo
driver: older FerretDB v1 builds reject {members:{$elemMatch:{userId,isActive:true}}}
with "(BadValue) unknown operator: userId". accessibleCardIds used exactly that
query, and the attachmentsList publication's catch swallowed the error, so the
report silently returned nothing. Current FerretDB handles $elemMatch; the build in
the test harness does not -- which is why board-load tests using a different query
still passed.
accessibleCardIds now matches board membership by the dotted path
{'members.userId': userId} (works on every FerretDB build) and confirms in JS that
the user's own member entry is active, preserving the exact per-element semantics
$elemMatch gives (a userId appears in at most one member entry). Verified with the
Mongo driver against both FerretDB v1.24.2 (was erroring) and v1.37.0: the full
pipeline now returns the 5 seeded attachments on both.
Thanks to xet7 !
The admin Files report has shown "No results" in every Playwright run (spec 41),
with nothing in the server log — because the attachmentsList publication swallowed
any error from its query in a catch that only logged when DEBUG=true. Stop hiding
it: the catch now always logs the error (with stack), and under DEBUG the
publication logs whether attachmentsReportQuery returned null (the user has no
accessible cards) versus a query that matched 0 attachments, so the two failure
modes are distinguishable.
Spec 41 now localizes the failure itself: it asserts the seed produced a real
cardId (so a null cardId, which would make meta.cardId never match, fails with a
clear message), and it probes getAttachmentsReportCount directly after opening the
report — that method runs the SAME accessibleCardIds + meta.cardId query the
publication uses, so if the server count is >= 5 but the table is missing it is a
client-render problem, and if it is 0 or errors it is the server query — instead of
just "table not visible".
No runtime is available in this environment to execute Playwright, so this makes
the next run point straight at the failing layer.
Thanks to xet7 !
Auto-detect the version instead of requiring one: if there is a
'# Upcoming WeKan ® release' section, rename it to the next version (the same
increment as the last release, e.g. 10.11 -> 10.12) dated today; otherwise use
the newest release heading (already renamed), sanity-checked as the +1 increment
and referenced by a recent commit so an old entry is never re-released. Explicit
'PREVIOUS NEW' args still override.
Thanks to xet7 !
Board import no longer asks for member mapping up front. Every imported member is
brought in as a virtual (placeholder) user carrying its avatar, username and full
name (the existing createPlaceholderUsers path), added to the board inactive with
no permissions. The client import flow is now a single step that imports
immediately with an empty mapping -- no map-members screen, nothing to get stuck
on.
Mapping a virtual member to an existing user is a deliberate, later action done by
a board admin from the board sidebar member-avatar popup ("Map to existing user"),
and CANNOT be used to gain privileges: the new board-scoped method
mapImportedBoardMember only maps a virtual member onto an existing ACTIVE, REAL
member of the SAME board and never changes that member's role (so no new
membership is created and nothing is escalated); authorization and this guarantee
live in the pure planBoardMemberMapping helper. The mapping reassigns the virtual
member's cards/comments/activities ON THAT BOARD to the target and removes the
placeholder from the board.
Automatic hang mitigation so an import can never spin forever: a client watchdog
surfaces an import-timeout and clears the spinner if importBoard does not answer in
WEKAN_IMPORT_TIMEOUT_MS (default 2 min), and the server bounds creator.create with
the same deadline via a new generic withDeadline() wrapper.
Covered by tests/boardMemberMapPlan.test.cjs (no-escalation + auth matrix),
tests/withDeadline.test.cjs (deadline wrapper) and tests/importVirtualMembers.test.cjs
(wiring).
Thanks to xet7 !
In the board/JSON import "Select member" popup, typed suggestions appeared but
neither clicking nor Enter assigned the user, so mapping a migrated board's
members to existing WeKan users was impossible. The click handler mapped
Template.currentData().__originalId -- a field that is never set on the search
results (they are plain WeKan user documents with _id) -- so it mapped undefined
and silently did nothing.
Map the clicked result by its _id, and add an Enter handler that selects the first
(highlighted) result so a name can be assigned by keyboard. Member mapping stays
optional: the step-1 "import without mapping" and the in-step "skip mapping"
buttons still import immediately (unmapped members default to the current user).
Guarded by tests/importMemberMapping.test.cjs.
Thanks to xet7 !
client/components/main/safeFilename.js registers the global Blaze helpers
cleanFilename and downloadFilename, but it was never imported on the client, so
the helpers were never registered. Every template that uses {{cleanFilename name}}
-- card attachment thumbnails (client/components/cards/attachments.jade) and the
admin Files report -- therefore threw "No such function: cleanFilename" during
render. On a card with attachments this aborted the card's Tracker recompute, so
clicking a card did nothing (the card would not open).
Import safeFilename.js from client/features/main.js alongside the other
client/components/main modules so the helpers are registered at startup. Guarded
by tests/fileNameDisplay.test.cjs.
Thanks to mueschel, brlin-tw and xet7 !
Fixes#6493,
Merely having MONGO_OPLOG_URL set makes Meteor start an OpLog tail at boot (a
tailable+awaitData cursor on local.oplog.rs) regardless of the reactivity order,
and on FerretDB that tail polls the database continuously -- pinning CPU even
with no clients connected. The polling-only branch of each launcher set
METEOR_REACTIVITY_ORDER=polling but left an already-set MONGO_OPLOG_URL in place,
so "polling only" still tailed the OpLog.
Every FerretDB launcher (snap wekan-control, bundled start-wekan.sh, Docker
wekan-entrypoint.sh, Sandstorm start.js) now actively clears MONGO_OPLOG_URL in
its polling-only branch, so choosing polling truly does no OpLog tailing. The
OpLog-enabled (default) path is unchanged. Covered by tests/ferretdbOplog.test.cjs.
This complements the FerretDB fork fix that stops awaitData from busy-polling the
tail in the default OpLog mode (wekan/FerretDB, wekan/wekan#6498).
Thanks to Alishara, bluetopaz1204, mueschel and xet7 !
Fixes#6498,
On a grain's first launch after upgrade, sandstorm-src/start.js migrates the old
MongoDB data to FerretDB v1 (SQLite) before starting WeKan. While nothing was
listening on the grain's app port (during migration and the handoff to WeKan),
sandstorm-http-bridge got connection-refused and the browser showed "This page
can not be displayed embedded in another page"; the user had to close the grain
and open it again.
start.js now runs migration-bridge.js as a child process on the app port that
answers every URL with a small auto-refreshing "please wait" page (HTTP 503), so
the grain stays framed until WeKan is up. It is a separate process on purpose:
start.js runs the migration with blocking spawnSync, so it could neither service
an in-process server nor release its listening socket before the importer/Meteor
bind the port -- killing a child is a definitive socket close. The bridge starts
before migration, YIELDS the port around the importer (which serves its own
progress dashboard there), resumes for the handoff, and is released just before
Meteor binds the port. Every use is best-effort (guarded by existsSync, error
handlers, killed on grain exit) so it can never break grain startup.
build-deps.sh ships migration-bridge.js next to start.js in the deps payload.
Thanks to xet7 !
During a #6492 data recovery, users should never see a bare connection error.
Two layers now cover the whole window on every FerretDB v1 launch path (snap,
bundled release, Docker):
- In-app spinner (already present): the server clears the RECOVERY_IN_PROGRESS
marker only after a real health probe, so the full-screen overlay behaves
identically everywhere.
- Static bridge page (new, cross-platform): for the brief window while a
just-restored FerretDB comes back up and before Meteor can serve the client,
the launch scripts serve a tiny standalone "recovering your data" page (HTTP
503) on the web port. The snap reuses wekan-maintenance-page.mjs with a
recovery wording; release/Docker serve the portable recovery-bridge.mjs. The
bridge is time-bounded (WEKAN_RECOVERY_BRIDGE_SECONDS, default 20s) so it can
never block WeKan from starting, hands straight over to the in-app spinner, and
is skipped if its page file or the marker is absent.
The launch scripts do NOT delete the marker; only the server does, after
verifying the database serves reads. Tests enforce the bridge is bounded, is
guarded by the page file, and that no script deletes the marker.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
#6492: while the SQLite text data is being recovered/remediated, users should see a
maintenance spinner instead of errors or half-loaded data.
- A published singleton status (models/recoveryStatus.js) carries an "active" flag +
message. The publication (server/publications/recoveryMaintenance.js) is PUBLIC so
even logged-out users on the sign-in page see it; the toggle method
(setRecoveryMaintenance) is admin-only.
- The client overlay (client/components/main/recoveryMaintenance.*) shows a full-screen
spinner + message when active; it is subscribed globally and rendered in both the app
(defaultLayout) and sign-in (userFormsLayout) layouts, above modals/popups.
- The startup scripts write a RECOVERY_IN_PROGRESS marker when they restore/re-migrate.
On startup the WeKan server (server/recovery.js) shows the spinner while the marker is
present, verifies the database serves reads (probe), then clears the marker and the
spinner — or, if it still cannot read, keeps the spinner and records that manual
recovery is required. Admins can also toggle maintenance for a server-initiated
re-migration.
Tests: tests/recoveryMaintenance.test.cjs (wired into npm run test:unit:node) — the
publication is public while the toggle is admin-gated, the overlay is subscribed and
rendered in both layouts above everything, the server shows the spinner from the marker
and clears it only after a health probe, and the scripts write the marker. Mirror-
validated (no Node runtime here); shell/brace/JSON all checked.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Completes the #6492 data-safety system on the WeKan side (FerretDB detection/repair/cap
landed in the fork):
- Decision brain: models/lib/recoveryPlan.js decideRecovery() picks the least-invasive
recovery when the database is KNOWN corrupt (latest good backup -> previous backup ->
re-migrate from MongoDB -> manual). It never acts on a healthy/unknown database and
never restores a known-bad backup.
- Startup restore/re-migrate: every FerretDB launch path (snap, bundled release, Docker)
can restore the text data BEFORE FerretDB opens the files, on request
(WEKAN_FORCE_RESTORE env or a RESTORE_REQUESTED marker). It copies a known-good backup
INTO the live database (dropping stale WAL side-files); backups are never deleted and
the main wekan.sqlite is only overwritten, never removed. remigrate is delegated to
migration-control. Attachments/avatars on the filesystem are untouched.
- Recovery events: the scripts append JSON lines to recovery-events.jsonl; the server
(server/recovery.js) imports them into the recoveryEvents collection on startup, plus
an admin-only recordRecoveryEvent method.
- Admin Panel / Problems / Recovery: a new admin-only report
(server/publications/recoveryReport.js, wired in adminReports.js/.jade + i18n) lists
the remediation history newest-first, readies up front and fetches directly (no hang).
- Docs: docs/Features/Admin-Panel/Problems/Recovery.md.
Tests (wired into npm run test:unit:node), verified by mirror since there is no Node
runtime here to execute them:
- recoveryPlan.test.cjs (decision logic, positive + negatives)
- recoveryEventsJsonl.test.cjs (parser: skips junk, normalizes severity, never throws)
- recoveryReportQuery.test.cjs (search selector escapes regex metacharacters)
- recoveryReportWiring.test.cjs (report wired; publication/count/method admin-gated)
- ferretdbTextDataBackup.test.cjs extended: restore copies from a backup, is
request-gated, and NEVER deletes the live text data or a backup copy
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Safety measure for #6492: before FerretDB opens its SQLite files (at rest), every
FerretDB launch path now keeps a rotating backup of the TEXT-DATA database
(wekan.sqlite*) in a "backup" subfolder of the same data dir, so a known copy is ready
to restore if the live database is ever detected corrupt (FerretDB's own quick_check
logs corruption on open). Attachments and avatars live on the filesystem and are not
copied.
The critical safety property: the backup only ever COPIES from the live database — it
never moves or deletes the live wekan.sqlite, and never wipes the data dir. The
previous generation is kept under backup/prev so a bad copy cannot overwrite the last
good one on its own. Disable with WEKAN_SQLITE_BACKUP=false.
- snap-src/bin/ferretdb-control
- releases/ferretdb/start-wekan.sh
- releases/ferretdb/wekan-entrypoint.sh
tests/ferretdbTextDataBackup.test.cjs verifies each path copies wekan.sqlite* into the
backup dir, keeps a previous generation, is guarded, and — the critical negative —
NEVER moves/deletes the live text data, never wipes the data dir, and never copies
attachments/avatars.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
Per the #6492 investigation, FerretDB v1's SQLite simulated OpLog (local.oplog.rs,
stored in the `local` database = local.sqlite) is not reliably capped, so over time
it bloats or corrupts; Meteor then busy-polls it and FerretDB CPU pegs at 300%+ even
when idle. A reporter confirmed that deleting local.sqlite* drops CPU straight back
to ~10%.
The `local` database is transient SYSTEM data — the OpLog + replica-set metadata,
NOT user data: boards, cards and attachments live in wekan.sqlite. So every FerretDB
launch path now resets ONLY the `local` database files before starting FerretDB,
which recreates a fresh, correctly-capped OpLog from --repl-set-name. This prevents a
corrupt/bloated OpLog from ever persisting across a restart:
- snap-src/bin/ferretdb-control
- releases/ferretdb/start-wekan.sh (bundled release, before each restart-loop start)
- releases/ferretdb/wekan-entrypoint.sh (FerretDB Docker image)
Guarded by WEKAN_FERRETDB_RESET_OPLOG (default true; set false to keep the OpLog).
tests/ferretdbOplogReset.test.cjs verifies each path resets local.sqlite, is guarded,
and — the critical safety property — NEVER deletes wekan.sqlite or the whole data dir.
Thanks to bluetopaz1204, mueschel and xet7 !
Fixes#6492,
On phones the two-column All Boards layout cut off text:
- The board icons column (the 1fr grid track) is a grid item, which defaults to
min-width:auto and would not shrink below its content, so the board tiles pushed
the column wider than the viewport and the board titles were clipped off the right
edge. Add min-width:0 to .boards-right-grid so the column shrinks to its track and
the tiles (and their titles) fit.
- The mobile board tiles reserved 50px on the right for the drag handle, which on a
narrow 2-per-row tile hid most of the title. Shrink the handle (40->26px) and the
reserved padding (50->30px) so more of the title shows.
- Workspace names in the narrow left menu were hard-cut mid-word ("Ro"); let the
flex children shrink (min-width:0) and truncate the name with an ellipsis so more
of it is readable ("Roadmap…").
Thanks to xet7 !
The report was still stuck on the loading spinner: an await in the publish body
never resolved, so this.ready() in the `finally` never ran and the subscription
never became ready (the report template only renders once ready). Two changes make
the publish always reach readiness:
- Call this.ready() UP FRONT, before any await, then stream the page rows with
this.added — the table populates reactively. The spinner can no longer get stuck
regardless of how slow/stuck the fetch is.
- Compute accessibleCardIds() by querying Boards / Cards directly with fetchAsync
instead of through ReactiveCache, and fetch the attachments page from
Attachments.collection directly — raw async fetches always resolve, avoiding the
ostrio FilesCollection cursor / backward-compatibility fallback that can hang.
Thanks to xet7 !
After keeping the board icons in their own right-hand column, the left menu
(Starred / Templates / Remaining / Workspaces / Add board) still could not be
scrolled: the fixed-height wrapper clips at 100vh, and only the board list had its
own scroll, so a menu taller than the screen had its lower items unreachable.
Give the left menu its own overflow-y:auto / bounded max-height so you can
drag-scroll down to its lower items, just like the boards column on the right.
Both columns are reachable in LTR and RTL — the layout uses a direction-aware grid
and logical inline borders, so under a dir="rtl" document the menu is on the right
and the boards on the left automatically. Spec 43 now also asserts the left menu
is a bounded scroll container.
Thanks to xet7 !
On phone-sized touch screens the All Boards layout collapsed to a single column,
so the board icons ended up BELOW the left menu and search bar. dragscroll does
not work over the menu / search area, so the boards below the fold could not be
reached by dragging — you could not scroll down to see more boards.
Remove the small-screen `grid-template-columns: 1fr !important` collapse: keep the
two-column layout (narrow minmax(84px,30%) left menu, board icons in their own 1fr
column on the right) in both mobile and desktop mode. The narrow minmax() menu
already prevents the old fixed-260px overflow that clipping-collapse was meant to
fix, and the board list keeps its own overflow-y:auto / dragscroll. Spec 43 now
also asserts the board list sits to the right of the menu, not stacked below it.
Also fix two WebKit-only test assertions (not app bugs): read the WebKit-prefixed
getComputedStyle(...).webkitUserSelect in the Statistics-view test.
Thanks to xet7 !
The 'attachmentsList' publication fetched via ReactiveCache.getAttachments(),
which reads through the ostrio FilesCollection cursor; when that returns no rows
it falls back to getAttachmentsWithBackwardCompatibility(), whose old-CFS lookups
can hang. The hang is INSIDE the publish's try block, so the finally this.ready()
never runs — the subscription never becomes ready and the Files report (Admin
Panel / Reports / Files) is stuck on the loading spinner, its content pane never
rendering (Playwright: the report table never appears in any browser). The other
admin reports query plain collections and were unaffected.
Query the plain Mongo collection directly (Attachments.collection.find) in both
the publication and the getAttachmentsReportCount method. The attachment rows live
in that same 'attachments' collection, so a direct find returns the page and always
completes: this.ready() fires and the report renders its table.
Thanks to xet7 !
The filesReport content pane rendered EMPTY in the newest Playwright run (no
title, no search box) — a throwing helper aborts the whole Blaze template. Guard
Attachments.collection access and never throw so the report UI always renders.
The core symptom (no attachments listed) is unverified/unfixed — it points at the
attachmentsList publication returning 0 rows, which needs a running server + DB to
diagnose. Correct the v10.07 changelog to stop claiming the report is fixed.
Issue #5659 reported that list-width defaults did not apply on public boards
(logged-out viewers) and that width settings only affected logged-in users. This
is already fixed by the models/lib/listWidth.js single-source-of-truth work:
resolveListWidth() returns the one DEFAULT_LIST_WIDTH (220) for every
uncustomized list and every viewer — members and logged-out public-board
visitors alike; the shared lists.width (#6409) applies to everyone; anonymous
viewers customize via localStorage. Verified against current source:
- resolveListWidth fallback order (mirrored, all cases incl. negatives pass)
- client list.js / listHeader.js and models/users.js import the shared module
with no stale 272/270 defaults; models/lists.js schema defaultValue is 220
The tests/listWidthDefaults.test.cjs regression test already existed but was not
wired into `npm run test:unit:node`, so it never ran. Wire it in so the #5659
fix stays verified.
Thanks to NadavTasher and xet7 !
Closes#5659,
The mobile board list is meant to be a BOUNDED, scrollable region
(height: calc(100vh - 120px)) so boards below the fold are reachable inside the
overflow:hidden wrapper (#6488). Two leftover .board-list.mobile-view rules
re-introduced the exact old bug: `min-height: 100vh` and a phantom
`::after { height: 100px }` forced the list to grow to its full content height,
so nothing ever overflowed — the list was as tall as its content and did not
scroll, and the lower boards were clipped and unreachable.
These non-media rules have higher specificity than the media-query block that
already sets the bounded height (whose comment notes min-height:100vh + ::after
was the bug), so they won this fight. Remove both; the bounded height now takes
effect and the two-column list scrolls.
Thanks to xet7 !
statsView.jade / statsView.js / statsView.css existed but were never imported
anywhere in the client build, so the `statsView` Blaze template was never
registered. The board body's `+statsView` include (selected when the user's
boardView is 'board-view-stats') therefore rendered nothing — the board header
showed "Statistics" (that only reflects the persisted boardView) while the
board canvas stayed empty. The Statistics view had never actually rendered.
Import the three files in client/features/boards.js alongside the other board
views (tableView), so the template, its helpers and its styles are in the bundle.
Thanks to xet7 !
The Files report (Admin Panel / Reports / Files) built its rows and count from
the ostrio FilesCollection wrapper (Attachments.find() / .count()). The
'attachmentsList' publication delivers the page via this.added('attachments', ...),
but the ostrio FilesCursor does not reliably re-run in a Blaze helper when those
docs arrive, so resultsCount stayed 0 and the `if resultsCount` table never
appeared (the report showed only its controls, no rows).
Read the underlying minimongo collection (Attachments.collection) instead, a
plain reactive Mongo.Collection cursor that reacts to the published adds and
yields plain docs — the same pattern the rest of the codebase already uses for
reactive attachment reads (sidebar backgrounds, backgrounds publication).
Thanks to xet7 !
The #6488 mobile All Boards test asserted the first two li.js-board tiles share
a row, but the list's leading '+ Add board' tile takes the first grid cell, so
the first two boards legitimately land on different rows in a 2-column grid
(the measured 194px is exactly one row). Measure every tile and assert the top
row holds >=2 tiles at two distinct x columns instead — a direct 2-per-row check.
The Statistics-view test switched via the board-view popup, which calls
Utils.setBoardView -> window.location.reload(); reloading the board cold mid-test
races the assertion (the board-canvas is still empty when it fires). Pre-seed
profile.boardView instead and load the board once, so statsView renders on the
first load without a mid-test reload.
FerretDB (v1 SQLite fork) does not implement MongoDB change streams: a
$changeStream aggregate returns "not implemented" and Meteor busy-loops
retrying it (high FerretDB CPU, cards never open). The snap fix 383b3dd43
already forced changeStreams out of METEOR_REACTIVITY_ORDER for FerretDB;
apply the same strip to the remaining FerretDB run-paths so changeStreams
can never enter the order however it was passed in:
- releases/ferretdb/start-wekan.sh (standalone FerretDB release)
- releases/ferretdb/wekan-entrypoint.sh (FerretDB Docker image)
- releases/ferretdb/start-wekan.bat (Windows, stripped at top level so
each set sees the previous line's result)
The Docker compose files already hardcode safe static values
(oplog,polling / polling, no changeStreams). start-wekan.sh and
start-wekan.bat at the repo root are the real-MongoDB path (they
initialise a replica set), where change streams are correct.
Thanks to uusijani, mueschel and xet7 !
Fixes#6492, #6493, #6480,
FerretDB v1 does not implement MongoDB change streams. The snap's general
default METEOR_REACTIVITY_ORDER is "changeStreams,oplog,polling", and it
arrives in wekan-control already set, so the FerretDB `:-oplog,polling`
fallback did not apply. Meteor then issued $changeStream aggregates that
FerretDB rejected as "not implemented" thousands of times per second - a
busy-loop that pinned FerretDB CPU (100-390%, 168% seen on 8 cores) and
starved board/card loading, so cards would not open (almost all commands
were those failed aggregates).
For FerretDB, force changeStreams OUT of the reactivity order whatever it
was set to, leaving oplog + polling; real MongoDB is unchanged and keeps
change streams. Polling-disabled path is polling only.
Thanks to xet7 !
Fixes#6492,
Fixes#6493.
setBoardView Meteor method did not await user.setBoardView(view), so it
resolved (and the client reloaded) before profile.boardView was written
and a rejected write never surfaced — switching the board view (e.g. to
the new Statistics view) was unreliable. Await it.
All Boards on phones now lays the board icons out as a real 2-column CSS
grid (repeat(2, minmax(0,1fr))) instead of float+width:50%, so at least 2
icons per row is guaranteed regardless of float-logical-value support or
how narrow the boards column is (#6488).
Thanks to xet7 !
Restructure the Upcoming WeKan release section like the released sections
and per docs/v10/Claude.txt: a new-features list and a fixes-the-following-bugs
list, each entry a link to its commit ending with Thanks to X and xet7,
closing with the thanks-to-translators line. Attribute the reported bugs
(mueschel for 6479 and 6480, mimZD for 6488).
Thanks to xet7 !
A moveCard trigger has no oldListName (the wizard chooses a destination
list, not a source), but findMatchingRules built the trigger query with
{ oldListName: { $in: [value, '*'] } }. Mongo's $in does not match a
document that is MISSING the field unless null is in the list, so the
trigger never matched and the rule's action silently never ran, with no
error. Add null to the match list for every field (a $in with null also
matches a missing field), exactly like the cardTitle handling (#2345).
Thanks to xet7 !
Fixes#6491.
From ../log/2026-07-20_15-26-39 (4 chromium failures; #6490 rules test
and spec 42 pass):
- Mobile All Boards (#6488): the real 1-per-row rule was
.board-list.mobile-view li { width:100% } (added via the isMiniScreen
class, more specific than the media-query rule) — set it to 50% too so
there are at least 2 icons per row. Seed 12 boards in the test so the
list definitely overflows and the scroll assertion is meaningful.
- Statistics view test: switch to the view through the actual board-view
switcher (js-open-stats-view) instead of pre-seeding profile.boardView,
which was flaky (localStorage vs profile / board-ready timing).
- Rules Workflow test (#6489): assert the palette renders with labelled
chips (the exact bug signature) instead of driving HTML5 drag-and-drop,
which Playwright's dragTo does not fire through Blaze's delegated
handlers here (the Add Rule button stayed disabled).
- attachmentsList: wrap the manual publish so this.ready() always runs
(finally) and drop the server-side name sort (no index; the client
re-sorts) — defensive against the still-unresolved Files-report hang.
Spec 44 exercises the two rules fixes end-to-end:
- #6490 (list view): seeds two rules, views the SECOND and asserts its
details show the second rule's trigger/action (not the first), then
deletes the second and asserts exactly it is removed (Alpha remains) -
client and server side.
- #6489 (workflow view): asserts the trigger/action palette renders (it
rendered nothing before the TAPi18n import fix), then builds a rule by
dragging a trigger + action into the slots and clicking Add Rule, and
asserts the rule appears and is persisted.
The mobile board list could not be scrolled: the CSS forced it
min-height:100vh (plus a phantom ::after), so it grew to fit all content
and, clipped by the overflow:hidden wrapper, boards below the fold were
unreachable. Give it a bounded height + overflow-y:auto so it scrolls
(natively on iOS; via the touch-drag handler elsewhere, which only
engages once content overflows).
Also improve the phone layout: keep the menu on the left but narrow it
(grid-template-columns minmax(84px,30%) 1fr) so the board icons on the
right show at least 2 per row (was 1 per row), on iPhone 12 mini and
similar. Add a phone-viewport Playwright test.
The Delete and View buttons are in the rulesList child template's each,
but their handlers are on the parent rulesMain and used
Template.currentData() — which returned the PARENT data context, not the
clicked rule. So the rule id was null: deleting failed with
'Match error: Expected string, got null', and 'View rule' always opened
the first rule. Add explicit data-rule-id to the buttons and read it in
the handlers so both operate on the rule actually clicked.
rulesWorkflow.js used TAPi18n without importing it, so paletteLabel()
threw 'ReferenceError: TAPi18n is not defined' and the Add Rule click
handler aborted before saving — creating a rule in the Rules -> Workflow
view silently did nothing. Add the missing import.
Move the board Status from a Board Settings sidebar popup into a
full-width board VIEW alongside Swimlanes / Lists / Calendar / Gantt /
Table in the board-view switcher. Named 'Statistics' (Finnish
'Tilastot'), translated to major languages (rest fall back to English).
New statsView template/js/css rendered from boardBody (isViewStats),
selectable via the switcher (js-open-stats-view -> board-view-stats,
added to the profile.boardView schema allowedValues). Reuses the server
boardStatus method so counts are accurate in lazy mode; shows the same
counts + time-spent summary as before. Text is selectable with mouse
(drag) and touch (long-press): the view stops pointer/touch events from
reaching the canvas drag-to-scroll so native selection + copy work.
Removed the old boardStatusPopup (template/handler/helpers/css) and its
Board menu item. Added a Playwright test for the view. Design doc
updated.
Apply the same fix as attachmentsList to the sibling paginated reports
rulesReport, boardsReport, cardsReport and impersonationReport: a
returned sorted+limited cursor makes Meteor set up a LIMITED live
observe that hangs on FerretDB's OpLog, so the report stays stuck on the
loading spinner. Each now fetches its page and the referenced docs and
publishes them with this.added + this.ready (into rules/actions/
triggers/boards, boards/users/team/org, cards/boards/lists/swimlanes/
users, impersonatedUsers/users respectively). No live cursor is needed
since the reports re-subscribe on every page/search change.
Add a Playwright test (spec 41) that opens each report and asserts it
loads (its search input renders once the subscription is ready).
attachmentsList returned a sorted+limited live cursor, so Meteor set up
a LIMITED live observe, which hangs on FerretDB's OpLog for this query:
the subscription never became ready and the Files report was stuck on
the loading spinner forever (spec 41). Publish the page manually (fetch
+ this.added + this.ready) so ready always fires; the report re-
subscribes on paging/search, so it needs no live cursor.
Also fix the two new #6479 Playwright tests: they located the member
avatar via '.membersWidget' which is a Blaze template NAME, not a DOM
class, so it never matched. Use the real sidebar container
'.board-sidebar' instead.
Move the flat feature docs and feature subdirectories under category
parents: Admin-Panel/ (+ Problems/), Board/, Cards/, Editor/, Reports/,
Automation/, Lists/, Troubleshooting/. Every relative markdown link in
docs/ (and the docs GitHub URLs in CHANGELOG.md and the code-span path
in Undo.md) is recomputed so it still resolves to the same target after
the move.
Done with a scripted move + relative-link rewriter that verifies link
integrity: all 160 rewritten links resolve, and a full scan confirms the
reorg introduces zero new broken docs-internal links (the pre-existing
53 unrelated to the move are unchanged).
New 'Board status' item in the board menu opens a larger, mouse-
selectable popup showing this board's card-loading mode (lazy vs all,
and whether chosen automatically), counts (swimlanes, lists, cards,
archived cards, labels, members, custom fields) and a time-spent summary
in the style of the task time reports (total hours, cards with time,
overtime cards).
Counts come from a server boardStatus(boardId) method so they are
accurate even in lazy mode, where minimongo only holds the visible card
window; the time summary fetches only cards with spentTime > 0 so it
stays cheap on big boards. New i18n keys translated to major languages
(rest fall back to English). Design doc at
docs/Features/Board/Sidebar/Status.md.
Move CPU-usage design under docs/Features/Admin-Panel/Problems/ and add
RAM-usage and Disk-usage design docs (siblings of CPU-usage): both log
how much RAM+swap / disk is used and record only the START and END of
each sustained high-usage period to Admin Panel / Problems, mirroring the
CPU-usage monitor's shape (hysteresis tracker, event stream, env vars).
Link them from the Admin-Panel index and update the now-automatic card
loading description. Update the CHANGELOG link to the moved CPU-usage.
Card loading is no longer an admin-configurable toggle. WeKan decides
per board by size ('auto', the default): a board over the threshold
(default 500 cards, CARDS_LOADING_LAZY_THRESHOLD) loads only visible
cards via windows; smaller boards keep loading all cards (unchanged,
fully featured). The server computes the mode per board and publishes it
(boardCardsLoadingMode -> boardCardLoadingModes) so client rendering
agrees; isLazyCards is now per-board.
Lazy windows now publish comments/attachments/checklists/checklistItems
with ONE cursor per window instead of one per card (same N+1 fix as
eager mode), and an open card subscribes to its own live children
(openCardData) so it is complete even when outside/just-added-to a
window. Operators can still force CARDS_LOADING=all|lazy|auto.
Removed the Admin/Features card-loading dropdown; pure decision logic in
models/lib/cardsLoading.js (resolveCardsLoadingMode now defaults to
'auto', plus effectiveBoardCardsMode + threshold) with updated unit
tests. New i18n key cards-loading-auto across locales.
#6479: the existing removal test only checked the DB, which is why the
bug shipped. Add a strict UI test that the removed member's avatar
disappears from the sidebar (plus a negative test that a non-admin is
offered no remove option).
#6480: add spec 42 verifying the board publication still shows a card
comment carrying boardId after the per-card -> board-level cursor
refactor (positive), and that a comment on a different board does not
leak in (negative — proves the board-level cursor stays boardId-scoped).
Removing a member keeps the entry with isActive:false (#5122, for role
history / re-activation), but membersForSidebar still listed inactive
entries, so Remove from board looked like it did nothing - the avatar
stayed. Show only active members (plus imported placeholders pending
reconciliation); removed members disappear from the list immediately.
Removed people still show greyed where they remain referenced (e.g. a
card assignee) via the existing inactive-member avatar styling.
Admin Panel / Problems / CPU usage could stay empty while FerretDB
pegged the machine: both WeKan and FerretDB measured only system-wide
CPU, and FerretDB at 170-300% (2-3 cores) is only ~40-75% system-wide on
a many-core host, below the high threshold.
Read FerretDB's new processCpuPercent from the throttle response and
surface it: high-CPU rows include it, and a new watch (a pure status
read that never slows FerretDB down, so it cannot make a slow board load
worse) records a start/end episode when FerretDB alone monopolises cores
even though system-wide CPU stays moderate. Tunable via
WEKAN_FERRETDB_WATCH_PERCENT / WEKAN_FERRETDB_PROC_HIGH_PERCENT.
Opening a board opened one live CardComments cursor AND one Attachments
cursor PER CARD. On a board with many cards that spun up thousands of
live observers; under FerretDB's poll-and-diff that pinned FerretDB/
SQLite CPU (170-300%) and made boards take minutes to open.
Publish comments and attachments with a single board-level cursor each,
on their denormalized boardId / meta.boardId (exactly like checklists) -
one cursor per collection instead of one per card, still reacting to
newly added cards. Add supporting indexes so the board-level queries are
not full scans: cards {boardId, archived}, cardComments {boardId},
attachments {meta.boardId}.
Lazy mode (boardCardsWindow) intentionally keeps per-visible-card
children (bounded by the window), so it is unchanged.
The paginated admin reports (Files, Rules, Boards, Cards, Impersonation)
only handled the subscription onReady callback, so if a report
publication errored on the server the report was stuck showing the
loading spinner forever, with no feedback. Handle onStop as well:
clear the spinner on stop and, on a real error, log it and surface the
message. This is defensive; it does not change the happy path.
The spec 41 "Files report shows clean filenames" test failed in all browsers
with `E11000 duplicate key error ... _id: "e2e-att-normal"`: it seeded
attachments with fixed _ids but never cleared leftovers from a previous run (or
another browser project sharing the DB), so insertMany hit a duplicate key.
- Clear the fixed attachment _ids with deleteMany({ _id: { $in: [...] } }) before
insertMany, so the seed is idempotent across re-runs and browsers.
- Also fix a latent bug: findCardIdByTitle was called with a string
('FilesCard') but it takes { boardId, title } and is synchronous. With a
string, EJSON drops the undefined fields and it matched an arbitrary card, so
the attachments would land on the wrong card and the report assertions would
fail once seeding succeeded. Now called as
db.findCardIdByTitle({ boardId: board.boardId, title: 'FilesCard' }).
Complete the high-CPU → FerretDB-slow-down → measure → report loop, and make it
robust when WeKan itself is CPU-starved or FerretDB is unresponsive.
- Adaptive feedback (server/lib/cpuMonitor.js): while CPU stays high WeKan now
INCREASES (doubles) the delay FerretDB adds between operations, up to a cap,
until system CPU drops below a headroom target (WEKAN_CPU_TARGET_PERCENT,
default 70) — enough CPU for other processes — then holds. Each escalation, the
headroom result, and the "even max delay not enough (load is elsewhere)" case
are logged.
- FerretDB self-regulates too: WeKan reads the throttle response's autoSlowDownMs,
hostCpuPercent and operationsSummary (what FerretDB has been doing) and logs
them — so the feature works even if WeKan is too starved to drive the loop.
- No flooding / no hammering (server/lib/ferretdbGovernor.js): every call has a
timeout (WEKAN_FERRETDB_TIMEOUT_MS); WeKan talks to FerretDB at most once per
WEKAN_FERRETDB_ASK_INTERVAL_MS (30s); a non-answer starts a cooldown
(WEKAN_FERRETDB_COOLDOWN_MS) instead of retrying. WeKan records WHEN FerretDB
became unresponsive and, on recovery, logs the full start -> end span plus
FerretDB's status and operations summary. "command not found" (plain MongoDB)
is still treated as permanently unsupported.
- i18n: cpuReportTitle ("CPU usage") translated to all 154 languages.
Guard tests (tests/cpuMonitorWiring.test.cjs) extended for escalation, rate-limit,
timeout/cooldown, outage span, and FerretDB self-regulation/summary. Docs
(docs/Features/CPU-usage/CPU-usage.md) and CHANGELOG updated.
FerretDB de-branded its custom command to the general name `throttle` (it is a
general-purpose MongoDB replacement, usable by any MongoDB-wire client, not only
WeKan). Update WeKan's caller to match: server/lib/ferretdbGovernor.js now sends
{ throttle: 1, ... } and the comments/guard test refer to the `throttle` command.
No behaviour change. WeKan-side names (ferretdbGovernor, slowDownFerretDb) are
WeKan's own and unchanged.
FerretDB is the other big CPU user on the same host. When WeKan's CPU monitor
detects a sustained high-CPU period it now asks FerretDB (via the custom
wekanThrottle command added to the bundled wekan/FerretDB v1 fork) what it is
doing and to slow down, and writes it to Admin Panel / Problems / CPU usage.
- server/lib/ferretdbGovernor.js: runs the wekanThrottle command over the raw
Mongo driver. slowDownFerretDb(slowDownMs, durationMs) asks FerretDB to pause a
few ms before each command for a short, self-expiring window and returns its
activity (commandsProcessed); resumeFerretDb() turns it off. Best-effort — on
plain MongoDB or an older FerretDB the command fails once and is never retried.
- server/lib/cpuMonitor.js: on 'start' asks FerretDB to slow down and logs a row
with FerretDB's reported activity and what it was asked; renews the
self-expiring throttle each sample while CPU stays high; on 'end' asks FerretDB
to resume and notes it. Tunable via WEKAN_FERRETDB_SLOWDOWN_MS.
Guard tests (cpuMonitorWiring) extended for the FerretDB governor. CHANGELOG +
docs/Features/CPU-usage/CPU-usage.md updated.
When CPU is high, the report now also records what automatic mitigation was
taken and whether it noticeably lowered CPU:
- Once the governor actually pauses a governed operation during a high-CPU
period, write ONE 'rate-limited' row: slowing down "<activity>" — pausing
200ms between steps to yield the CPU (also lowers FerretDB query load), with
the CPU% at slow-down start.
- Track the lowest CPU% seen after slowing down; the 'end' row reports the
effect: "slowed down <activity> (paused N times, Xs total). After slowing
down, CPU went A% -> B% — noticeably lower (about -Z points)" (or "not
noticeably lower"). When nothing was running to slow down, it says so.
Still at most three rows per episode (start, mitigation, end). The effect is a
correlation over the sampling window, reported as observed.
Also rename the design doc to docs/Features/CPU-usage/CPU-usage.md (CHANGELOG
link updated). Guard test extended for the mitigation logging.
WeKan and FerretDB on one machine can drive CPU high enough to starve other
software. Add a monitor, a governor, and a report. Design: docs/Features/CPU/CPU.md.
Monitor (server/lib/cpuMonitor.js): samples system-wide CPU% from os.cpus()
idle/total deltas on an interval (so it includes WeKan, FerretDB and every other
process). A pure, hysteresis state machine (models/lib/cpuHighTracker.js) turns
the samples into ONLY the START and END of each sustained high-CPU period — two
rows per episode, never a flood. Enters high after 3 consecutive samples >= 85%,
leaves after 3 consecutive < 70%. Each row carries duration, peak, system load,
and what WeKan was doing (setActivity label). Recorded to a new 'cpu' event
stream (server/lib/cpuLog.js).
Governor: cpuMonitor exports isHighCpu() and pauseIfBusy(), so long batch
operations await a short pause and yield the CPU only while the system is busy
(no cost when idle). Wired into the existing-file extension corrector. Tunable
via WEKAN_CPU_* env vars.
Report: 'cpu' added to EVENT_STREAMS; reuses the generic eventStreamReport
(stream="cpu") with search + pagination; a "CPU usage" item is added to the
Admin Panel / Problems side menu (cpuReportTitle i18n).
Tests: cpuHighTracker unit (start/end, duration/peak, no-flap hysteresis;
positive + negative) and cpuMonitorWiring source guards. CHANGELOG + design doc.
Whenever a filename or file requires sanitization — on upload, migration, the
existing-file corrector, or viewing/serving — record it to the Security event
stream (action:'sanitized'), the companion to the existing action:'blocked'
upload rejections. Each row carries:
- WHEN: the event timestamp.
- WHO: the original uploader (userId), shown as a new clickable username column
in the Problems event report.
- FOR WHAT REASON: sanitizationReasons() — URL-encoded name, invisible
characters, typosquatting (look-alike characters), the specific exploit KIND
(JavaScript code, XML code, XML loop (billion laughs), server-side PHP/ASP,
template injection, HTML code), wrong file type (.txt -> .png), filename too
long, or empty-name-generated.
- THE FILENAME: "from" -> "to".
- WHERE: board > swimlane > list > card, plus the board's organization(s) and
team(s) (server/lib/fileContext.js).
New: classifyExploitKinds() + sanitizationReasons() (isomorphic), the
server-only fileContext resolver, filenameSanitizeLog helpers, catalog keys
file.sanitize / file.content / file.malware, and the uploader column in the
event report. Wired at all fix points (attachments/avatars onAfterUpload,
moveToStorage, correctFileExtensions, httpStreamOutput). EICAR now uses the
file.malware key. Logging is best-effort and never breaks the upload/view path.
Tests: classifyExploitKinds + sanitizationReasons unit tests (positive +
negative) and logging-wiring source guards. CHANGELOG + design doc updated.
One unified filename subsystem, used everywhere a name is shown, uploaded,
served, or migrated. Design: docs/Features/Filename/Filename.md.
Display (imports/lib/fileNameDisplay.js, general cleanFileName + global
{{cleanFilename}}/{{downloadFilename}} helpers): URL-decode, normalize to
generally-used characters (NFKC + confusable-homoglyph folding so typosquatting
"payp<Cyrillic-a>l.exe" shows as "paypal.exe", only in a Latin-majority base so
genuine non-Latin names are preserved), remove invisible/control/bidi chars,
strip HTML/JS/XML/template markup. Removed the earlier invisible-char filter
button, warning triangle, inline descriptions, legend and server invisibleOnly
filter.
Upload (attachments + avatars, all backends): reject exploit-looking filenames
and EICAR virus test files; strip invisible chars; correct the extension to the
real detected type (double-click opens the right app); type-based name when
empty; cap length to a portable max (30, Amiga OS FFS) preserving the extension;
sanitize SVG JS / XML-loop content at the staging location before promoting to
final storage and delete the temp file after; enough-disk-space check with
small-RAM streaming and stop-and-remove-partial on any write error.
Existing files: general storage-agnostic detector streams a small header to
WRITABLE_PATH/files/temp, runs `file`, deletes the temp file; admin-only bounded
batch extension corrector; serve-time on-the-fly exploit sanitizer wired into
httpStreamOutput (sniffs the start, rewrites only dangerous markup, streams the
rest unchanged).
Migrations (moveToStorage/copyFile): sanitize content, finalize the name with
the same general function (detected type, corrected extension, folded
homoglyphs, capped length), save it at the destination, and number
same-name/different-content collisions (document.pdf, document-1.pdf, ...).
Tests: rewrote fileNameDisplay.test.cjs; added uploadFileName, diskSpace,
fileTypeCorrection and fileHardeningGuards unit tests (positive + negative);
updated Playwright spec 41 to the clean-name model. CHANGELOG + design doc.
Made the Files-report filename rendering a GENERAL, reusable component and used it
everywhere filenames are shown:
- New client/components/main/safeFilename.{jade,js,css}: +safeFilename(name=...)
URL-decodes the name, shows a red warning triangle when it hides invisible
characters, and replaces each invisible character inline with its red Unicode
name (all escaped plain text — never markdown/HTML). Plus two global helpers:
{{filenamePlain name}} (decoded name, invisible chars named — for title="" / JS
text) and {{downloadFilename name}} (decoded + invisible chars REMOVED).
- Used it in the Admin Panel → Files report and the card attachments (visible
name via +safeFilename; thumbnail title via filenamePlain; the download="" attr
via downloadFilename; the attachment viewer title via fileNamePlain()).
- Downloads now save a CLEAN name: the Content-Disposition sanitiser in both
server/routes/universalFileServer.js and legacyAttachments.js runs the name
through sanitizeDownloadFileName (URL-decode + remove all invisible/format/bidi
characters), never empty (falls back to "download").
New fileNamePlain()/sanitizeDownloadFileName() in imports/lib/fileNameDisplay.js;
unit + negative tests in tests/fileNameDisplay.test.cjs.
Thanks to xet7 !
Instead of colouring the entire filename red, the Files report now:
- shows a red warning triangle (fa-exclamation-triangle) to the left of any name
that hides invisible characters; and
- replaces each invisible character IN PLACE with its red Unicode description,
e.g. "evil[U+200B ZERO WIDTH SPACE].png" — the visible parts keep the normal
text colour.
New fileNameSegments()/describeInvisibleChar() in imports/lib/fileNameDisplay.js
split the (decoded) name into visible runs + one named segment per invisible
character (bracketed "U+XXXX NAME", falling back to the code point for unnamed C1
controls). Everything is still rendered as escaped plain text (Blaze `{{ }}`) —
never markdown/HTML. Unit + negative tests in tests/fileNameDisplay.test.cjs and
the Playwright spec updated to assert the warning + inline names.
Thanks to xet7 !
New spec tests/playwright/specs/41-admin-newest-features.e2e.js:
- Files report: seeds attachments (normal, URL-encoded "%D0%93%D1%80" -> "Гр", and
one hiding a zero-width space) and asserts the encoded name is DECODED, the
invisible-char name is flagged red (.filename-invisible), the invisible-only
filter lists only it (and a NEGATIVE toggle-off brings the others back), there is
NO Search button, and the search field + pagination controls + legend are shown.
- Version (Information) page: shows the live Reactivity mode plus the configured
METEOR_REACTIVITY_ORDER and DDP_TRANSPORT rows.
- NEGATIVE: the board Table view has no clickable-sortable headers (removed).
Thanks to xet7 !
The archived-boards list published EVERY archived board the user can delete at
once (unbounded, grows on long-lived instances). It now pages server-side
(searchTerm + limit/skip, 30 per page) with a getArchivedBoardsCount method, and
the template gained a search field + prev/next controls in one row (matching the
Admin report tables). Only the current page is ever loaded into the browser.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
Per request, clickable column-header sorting is removed everywhere it existed:
- Board Table view: the sortable `th.js-table-view-sort` headers become plain
headers; the sortField/sortDirection state, the sort click handler and the
sortIndicator arrow are gone. The table now always shows a stable order (card
title ascending). Search + pagination are unchanged.
- Admin Panel → People → Domains: same removal; the getDomainsWithUserCountsPage
method no longer takes sortField/sortDirection and returns a fixed domain-
ascending order (paginateDomains' default). Server-side search + pagination stay.
Dead sort-header CSS removed. Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
Translated filter-invisible-filenames and filename-invisible-legend (the
invisible-only filter button + the red legend) to all 153 languages.
Thanks to translators and xet7 !
The Translation report subscribed with a hardcoded limit of 0, which Mongo/
FerretDB treat as "no limit", so the page loaded EVERY translation string across
all languages into the browser at once. It now passes the infinite-scroll window
(page * 25), so it loads a page at a time and grows as you scroll — the same
bounded pattern the activity feed uses. Guarded in
tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
WeKan buttons hardcoded their colors, so a Member Settings → Change color theme
override never reached most of them (customTheme.css only themed
`button[type=submit].primary`, not plain `button.primary`, and the global button
base was solid black). Now the global button base and the primary buttons in
client/components/forms/forms.css use `var(--theme-accent, <original>)`, and the
admin action buttons (settingBody.css) and People-panel buttons (peopleBody.css,
incl. ext-box / add-remove-team / unlock-all) do the same. The fallback keeps the
default look identical, but once the user picks a theme accent, the buttons across
the app follow it.
Guarded in tests/buttonThemeColors.test.cjs.
Thanks to xet7 !
At Admin Panel → Problems → Files report:
- Percent-encoded filenames (e.g. "%D0%93%D1%80" -> "Гр") are URL-decoded for
display when they decode cleanly; malformed/partial encodings are left as-is.
- Filenames are always shown as PLAIN TEXT — Blaze `{{ }}` HTML-escapes, so a
name is never rendered as markdown or HTML.
- A filename hiding invisible / control / bidi / zero-width characters (after
decoding) is shown in RED. A translated legend on the right of the pagination
controls explains that red = invisible characters.
- A board-view-style filter toggle lists ONLY filenames containing invisible
characters (server-side, so it works across the whole paginated set); clicking
it again removes the filter.
New isomorphic helper imports/lib/fileNameDisplay.js (decodeFileNameSafe,
hasInvisibleChars, INVISIBLE_CHARS_SOURCE) is used by both the client (display +
red flag) and the server (the invisibleOnly query on attachmentsList /
getAttachmentsReportCount). Unit + source-guard tests in
tests/fileNameDisplay.test.cjs. English strings added; translations follow.
Thanks to xet7 !
Across the Admin Panel → Problems report tables (Files/Rules/Boards/Cards/
Impersonation) and the People/Org/Team/Domain tables:
- Removed the redundant "Search" button — typing in the field + Enter already
searches (the keydown handler was already there); dropped the now-dead
js-*-search-button click handlers.
- Put the pagination controls on the RIGHT of the search field, in one row
(margin-inline-start:auto, so it mirrors correctly in RTL), matching the
Security/Speed/Tests event table which already had this layout.
- Made the pagination controls follow the current theme: they now use
var(--theme-accent, #01628c) instead of hardcoded blue/grey/white, so they
honour Member Settings → Change color (which sets --theme-accent on :root) and
fall back to WeKan blue when no custom theme is chosen. The event-stream
pagination links are themed too.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
The Admin Panel → Problems → Cards report already paginates (limit/skip), but it
sorted by { boardId:1, sort:1 } which has NO index, so every page load full-sorted
all cards in memory — the spinner on a site with 11761 cards. Switched both the
cardsReport publication and the client mirror sort to { boardId:1, createdAt:-1 },
the existing index (server/models/cards.js), so one page is a bounded index scan.
Also added a { stream:1, at:-1 } index on the eventlog collection (and { stream:1 }
on eventlogAcks) so the Security/Speed/Tests report pages stay an index scan as the
log grows, instead of a full scan + in-memory sort.
Guarded in tests/adminReportsPagination.test.cjs.
Thanks to xet7 !
The Admin Panel → Problems detail methods eventLogCount/eventLogPage awaited
requireAdmin() BEFORE check()ing their arguments. When requireAdmin throws (a
non-admin call, or before admin status resolves on the client), Meteor's
audit-argument-checks runs and throws "Did not check() all arguments during call
to '<method>'", masking the real error and spamming the server log. Moved the
check() calls to the top of both methods, before any await/throw — matching
acknowledgeEventLog, which was already correct. Guarded in
tests/securityLog.test.cjs (check() must precede requireAdmin in every
argument-taking method).
Thanks to xet7 !
Sandstorm defaults to FerretDB but its grain launcher (sandstorm-src/start.js) set
neither --repl-set-name nor MONGO_OPLOG_URL / METEOR_REACTIVITY_ORDER, so it stayed
on poll-and-diff. Now the STEADY-STATE FerretDB is started with --repl-set-name=rs0
and WeKan is pointed at it with METEOR_REACTIVITY_ORDER=oplog,polling (OpLog only
when tailing works, polling fallback). The transient migration-target FerretDB stays
OpLog-free so bulk inserts are not slowed. WEKAN_FERRETDB_OPLOG=false forces polling.
This makes every platform that defaults to FerretDB — Snap, Sandstorm, Docker and
the prebuilt bundle — behave the same. Guarded in tests/ferretdbOplog.test.cjs.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
The FerretDB OpLog work added two Admin Panel → Version row labels
(Reactivity_order, DDP_transport). Translated both to all 153 languages, keeping
the environment-variable names METEOR_REACTIVITY_ORDER and DDP_TRANSPORT literal
inside the parentheses in every language (including RTL and non-Latin scripts).
Thanks to translators and xet7 !
Below the live "Reactivity mode" (oplog / changeStreams / polling — what is
actually running) and "MongoDB Oplog enabled" rows, the Version page now also
shows what was REQUESTED via the environment: the reactivity driver priority
order (METEOR_REACTIVITY_ORDER, falling back to DEFAULT_METEOR_REACTIVITY_ORDER)
and the DDP transport (DDP_TRANSPORT). Together they let an admin see at a glance
"I asked for oplog,polling and it is actually running oplog" vs "it fell back to
polling". The values are returned by the existing getStatistics() server method
(reading process.env), not exposed as public settings. Empty env shows '(unset)'.
New i18n keys Reactivity_order and DDP_transport; guard in tests/ferretdbOplog.test.cjs.
Thanks to xet7 !
Follow-up to enabling the FerretDB OpLog by default (#6480, #6481). Setting
MONGO_OPLOG_URL alone can make Meteor fail to start if OpLog tailing does not
actually work (the same way WeKan on Windows with MongoDB falls back to polling).
Fix: every FerretDB launch path now also sets
METEOR_REACTIVITY_ORDER=oplog,polling — Meteor tries the drivers left-to-right and
uses OpLog ONLY when tailing works, otherwise polling, so a broken/absent OpLog
never blocks startup. Previously only docker-compose set this; the snap
(wekan-control), the bundle (start-wekan.sh/.bat) and the docker entrypoint
(wekan-entrypoint.sh) set MONGO_OPLOG_URL WITHOUT the polling fallback. The
kill-switch path (WEKAN_FERRETDB_OPLOG=false) now selects polling-only.
Admin Panel / Version already reports which driver is actually live: server/
statistics.js derives "Reactivity mode" (oplog / changeStreams / polling) and
"MongoDB Oplog enabled" from Meteor's live _oplogHandle, so it shows `polling`
whenever OpLog did not come up — the direct way to confirm whether FerretDB is
on OpLog or polling.
Tests: tests/ferretdbOplog.test.cjs now asserts the oplog,polling fallback in
every launch path, the polling-only kill-switch path, and that the Version page
detects + displays the live reactivity driver.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
With FerretDB there is no MongoDB oplog, so Meteor observed every live query by
poll-and-diff, pinning FerretDB CPU at 100-390% on busy boards (#6480, #6481).
FerretDB v1 now ships an OpLog (wekan/FerretDB: auto-created capped local.oplog.rs
+ replica-set hello handshake), so every FerretDB launch path now:
- starts ferretdb with --repl-set-name=rs0 (snap ferretdb-control, docker
entrypoint + docker-compose service, bundle start-wekan.sh/.bat), which makes
FerretDB auto-create the OpLog and advertise the replica set; and
- points WeKan at it with MONGO_OPLOG_URL=.../local?replicaSet=rs0 (docker-compose
also switches METEOR_REACTIVITY_ORDER to oplog,polling), so Meteor TAILS the
OpLog instead of polling.
Enabled by default with a kill-switch: WEKAN_FERRETDB_OPLOG=false forces the old
polling-only behaviour. The calmer polling defaults remain as the fallback for
queries Meteor cannot observe via the OpLog. The transient migration ferretdb
(migration-control) deliberately stays oplog-free so bulk inserts are not slowed.
Also cut the client activity feed page from 500 to 50 rows: 500 was far more than
the sidebar/card feed shows and, under polling, was re-fetched and re-diffed on
every poll; infinite scroll still loads more on demand (the server cursor is
index-bounded either way).
Tests: tests/ferretdbOplog.test.cjs source-guards every launch path (repl-set arg,
MONGO_OPLOG_URL, kill-switch) plus the activity page size, and a negative test that
migration-control stays oplog-free.
Thanks to uusijani, Nissulya and xet7 !
Fixes#6480,
Fixes#6481.
#6481 (Nissulya): after MongoDB 3.x -> FerretDB v1 migration, cards with a
non-finite `sort` (±Infinity / NaN, written by old WeKan before #6472) failed to
insert: FerretDB/SQLite rejects non-finite doubles ("invalid value { sort: +Inf }
(infinity values are not allowed)"), aborting the document and leaving boards
stuck on the loading spinner. sanitizeNonFinite() only made the bare mongoexport
tokens PARSE; the parsed value was still a JS Infinity/NaN. Added clampNonFinite()
in the migration tool to reset every non-finite number to a finite 0 before
insert, and a `nonfinite-sort-repair` startup schema-upgrade step that heals the
same corruption in an already-running database (MongoDB or FerretDB), using a
predicate built from finite literals only so it is safe on FerretDB too.
#6481 (Nissulya): LDAP `mail` -> `email` fieldmap returned `undefined` (worked in
6.09). getDataToSyncUserData's email branch read the mapped attribute
case-SENSITIVELY (ldapUser.hasOwnProperty / ldapUser[field]) while the rest of
wekan-ldap uses the case-insensitive getLDAPValue(); a directory returning the
attribute with a different case (exposed by ldapjs -> ldapts, which preserves the
server's case) missed it. The email branch (and the addLdapUser fallback) now
read via getLDAPValue().
#6480 (uusijani): board/CSV export paused on socket backpressure with
`res.once('drain', resolve); res.once('error', reject)`, which leaked one 'error'
listener per backpressured write ("MaxListenersExceededWarning: 11 error
listeners added to [ServerResponse]"). writeWithBackpressure() now removes both
listeners once either settles.
Added tests and negative tests for all three fixes.
Thanks to Nissulya, uusijani and xet7 !
Fixes#6480,
Fixes#6481.
Fix the intermittent "Unexpected userId after login" e2e flake (seen in
33-board-domains, which re-logs-in on the same page: admin then non-admin).
Meteor.userId() can lag the Meteor.loginWithToken callback by a tick, so reading
it immediately sometimes returned the PREVIOUS userId. Poll Meteor.userId() until
it settles on the expected id (5s timeout so a genuine mismatch still surfaces).
Pure test-helper change; the direct-Mongo-seed + resume-token login path this
uses does not go through createUser, so it is unaffected by the session security
changes.
Add server/lib/selfChecks.js: at startup (and via an admin-only runSelfChecks
method) run cheap invariants a unit test would assert (database round-trip,
WRITABLE_PATH/files writable) and record any failure to the Tests stream
(Admin Panel -> Problems -> Tests). WeKan does NOT require Playwright: only
failures detectable without a browser are logged, and no runtime code imports
Playwright (asserted by the test). Wired into server/imports.js; design doc
updated.
Add server/lib/speedMiddleware.js: a WebApp middleware that times non-asset HTTP
requests and records those slower than WEKAN_SLOW_REQUEST_MS (default 2000ms; 0
disables) to the speed stream via speedLog. Best-effort, never throws; wired into
server/imports.js. Source-guard test added.
Record more runtime rejections into the eventlog (Admin Panel Problems):
- fileValidation.js: log every upload rejection (dangerous MIME content ->
xss.mime, mime not on the allow-list -> file.mime, over size limit ->
file.size).
- metrics.js: log spoofing.xff when a /metrics request carrying an
X-Forwarded-For header is denied (likely forged-whitelisted-IP attempt).
- export.js: log authz.export at all four export-authorization denial paths.
All calls are best-effort/guarded (server-only require, try/catch) so logging
never breaks the guard. Source-guard tests added.
Translate problems, summary, securityReportTitle, speedReportTitle,
testsReportTitle, new-problems, acknowledge, no-new-problems,
problems-summary-help and the event-* table headers into all 153 non-English
languages (en is the source). All files validated as JSON.
- 2nd header bar: add a Problems button (warning icon) to the RIGHT of the Info
(version) button; it turns red when there are new problems (settingHeader.js
polls eventLogProblemAreas). Remove the old Reports button; the Admin Panel
still opens on Settings.
- The former Reports page is now the Problems page: left menu Summary / Security /
Speed / Tests, then a separator, then the moved Broken Cards/Files/Rules/Boards/
Cards/Impersonation items.
- Summary (problemsSummary, renamed from the removed top banner): the checkbox
list + one Acknowledge button — the ONLY place to acknowledge.
- Security/Speed/Tests: read-only, paginated, searchable event tables via new
admin-only eventLogPage/eventLogCount methods; acknowledgeEventLog now takes a
stream or array.
- i18n keys + CSS + source-guard tests + design doc updated.
Change the top problem banner from a per-area button to a checkbox list of
problem areas with a single Acknowledge button that acknowledges every checked
area in one call. acknowledgeEventLog now accepts a stream or an array of
streams. Acknowledging happens ONLY at the top banner; the Reports pages are
read-only (noted in the design doc).
Like the Announcement banner, the Admin Panel top now shows, for each problem
area with unacknowledged events, its menu path (Admin Panel -> Reports ->
Security/Speed/Tests) and the count of NEW problems. Each area has an Acknowledge
button that marks the newest problems seen, zeroing the count and removing the
info from the top.
- models/eventLog.js: add the eventlogAcks collection and admin-only methods
eventLogProblemAreas() (count of events newer than each stream ack) and
acknowledgeEventLog(stream) (upsert ack = now).
- client adminProblemBanner.{jade,js}: poll the counts, render path/count/button,
acknowledge on click; included in settingHeaderBar (top of every admin page).
- i18n keys (securityReportTitle/speedReportTitle/testsReportTitle/new-problems/
acknowledge) + banner CSS. Source-guard tests added.
Per correction: use only the existing WeKan database via Meteor JavaScript
queries (works on FerretDB and MongoDB); do not create files/DBs under
WRITABLE_PATH; and have FerretDB report problems to WeKan rather than writing
itself.
- models/eventLog.js: one `eventlog` collection (stream: security|speed|tests).
- server/lib/{securityLog,speedLog,testLog}.js: thin wrappers that insert one
document via EventLog.insertAsync (fire-and-forget, never throw).
- models/lib/securityLogFormat.js slimmed to just sanitizeDetail; remove the
node:sqlite event store (server/lib/eventStore.js) and all file/path/schema
helpers.
- Add a Tests stream: log anything that would fail an existing WeKan test.
- Design docs (WeKan.md, FerretDB.md) rewritten: DB-collection storage, grouped
counts for the summary, Admin Reports read the collection, and FerretDB reports
problems to WeKan which records them (no FerretDB DB/file writes).
- tests/securityLog.test.cjs updated (sanitizer + catalog + collection wiring +
no-filesystem guards); verified via Python mirror.
- Avatar localization redirect SSRF: fetch avatars via fetchSafe (DNS-pinned,
redirects rejected) instead of native redirect:follow, and validate
profile.avatarUrl scheme (http/https/data:image/local) at write time.
- Trello import source.url stored XSS: only render/store an http(s) activity
source URL, so a javascript: board url can no longer execute on click.
- Trello LIVE import readable SSRF: gate every attachment/background/avatar
download with validateAttachmentUrl, matching the offline import path.
- CAS login global user-data race: store validated CAS user data per credential
token instead of a module-global _userData (fixes account-takeover race).
- Metrics X-Forwarded-For whitelist bypass: only trust XFF behind
METRICS_TRUST_PROXY (parsed spoof-resistantly from the right); else use the
socket peer address.
- Stale impersonation export bypass: remove the "|| impersonateDone" export
authorization bypass; require real board visibility (canExport) only.
- Invitation code brute force: generate invitation codes with a 128-bit CSPRNG
(crypto.randomBytes) instead of a 6-digit Math.random value, and rate-limit
createUser (DDPRateLimiter).
The OIDC shared serviceData race from the same report was already fixed (#4897,
the per-login objects are callout-local). Source-guard regression test added
(tests/securityMeifukun.test.cjs) and wired into test:unit:node.
Thanks to meifukun and xet7 !
Wire in three new publish jobs (dormant until their secrets are set — each
guards on its secrets and skips with a ::notice:: so ordinary releases are
unaffected):
- snap-variants: build+publish wekan-ondra and wekan-gantt-gpl snaps.
- ucs: bump + push the wekan/univention app and upload to the App Provider.
- nextcloud: build the ExApp image and publish to the Nextcloud App Store.
Document the new secrets in the header. Add a "Remaining steps" section to the
top of Snap-Ondra-Gantt.md, UCS.md and Nextcloud.md (keys to add + how).
The 29 per-OS manual-vs-automatic update comparison docs move into OS/;
the WeKan-specific docs (README, Snap, Snap-Ondra-Gantt, UCS) stay in the
parent. All cross-links repointed and verified.
Add manual-vs-automatic (Snap-like) update comparison docs for all operating
systems with any Internet update mechanism: Linux, BSD, Haiku, Amiga, RISC OS,
Solaris/illumos, AIX, HP-UX, OpenVMS, z/OS, ArcaOS, ReactOS, FreeDOS, Plan 9,
Redox, SerenityOS, Android, iOS, ChromeOS, HarmonyOS, Ubuntu Touch, Sailfish,
postmarketOS, KaiOS, Tizen, webOS and TV/streaming OSes; plus a README index.
Add Snap-Ondra-Gantt.md (keys/secrets + release-all.yml changes to also release
the wekan-ondra and wekan-gantt-gpl snaps). Rename the two earlier dev docs to
Snap.md / Windows.md and repoint all links.
- i18n: registering generic Chinese (zh) as its own entry made bare "zh"
resolve to itself, so the "zh -> zh-Hans" alias is now dead code — remove it
from LANGUAGE_ALIASES (keep wuu -> wuu-Hans) and update the two mocha tests
(resolveTag/setLanguage) to expect "zh" instead of "zh-Hans".
- e2e (15-board-actions): the Board Settings cog was removed from the header
(it is in the right sidebar now), so the "one click from the header cog" test
failed in every browser. Rewrite it to open the sidebar and open the board
menu (which still has Archived Items) from there.
The changes committed since the v10.00 release bump had no CHANGELOG Upcoming
section. Add one above v10.00 covering all of them: the "Submit editors with
Enter" Member Setting, the right-sidebar drag-to-resize width feature, the #6481
migration NaN/Infinity fix, the #6465 Add List inline-composer options restore,
the right-sidebar width/inputs fix, and the missing copy-selection key — each
with commit links.
Add the sidebar resize handle tooltip (drag-to-resize-sidebar, "Drag to resize
sidebar") to every language file, translated into each language (English-variant
locales carry the English text). All 154 files JSON-validated; value-only
additions.
Add a resize handle on the sidebar edge, like resizing a spreadsheet column
(mirrors the list resize in client/components/lists/list.js). Drag it to change
the sidebar width; the width is saved to profile.sidebarWidth for logged-in
users and to browser localStorage (wekan-sidebar-width) for anonymous users on
a public board, then re-applied on load.
- The handle uses the LOGICAL inset-inline-start, so in LTR it is the left edge
of the right-docked sidebar and in RTL it is the RIGHT edge of the left-docked
sidebar; the drag direction inverts for RTL so dragging always widens/narrows
the visible panel correctly.
- Desktop only: on phones (<=800px) the handle is hidden and the sidebar stays
full width (the 100vw rule is now !important so a desktop inline width can
never leak into mobile).
- Width is clamped (min 280px, capped near the viewport) and re-applied on
window resize so crossing the mobile breakpoint clears/restores it.
New profile.sidebarWidth schema field + getSidebarWidth/setSidebarWidth helpers,
setSidebarWidth Meteor method, i18n (en, fi), and source-guard test
tests/sidebarResize.test.cjs.
Thanks to xet7 !
The Multi-Selection right-sidebar "Copy selection" button used {{_ (quote)copy-selection(quote)}}
but the key was missing from every language file — including the en source —
so i18next had no value to fall back to and rendered the raw key. Add
copy-selection ("Copy selection") to en and translate it to all languages,
mirroring each language(apos)s existing "move-selection" sibling with the verb changed
to copy. All 154 files JSON-validated; value-only additions.
Thanks to xet7 !
- .board-sidebar used width: 30vw, which scaled with the viewport: on very wide
screens it grew to ~double the intended width (it looked right only at mid
widths). Use width: clamp(320px, 30vw, 560px) so it keeps the mid-width look
but is capped (and floored) instead of scaling without bound. Phones (<800px)
still get the full-width 100vw rule.
- The sidebar filter text inputs (Filter List by Title, Filter by card title,
advanced filter) had no width, so they rendered at the browser default narrow
width with a big empty gap on the right. Sidebar text/search inputs now
width: 100% + box-sizing: border-box, so they fill the padded content area
with equal empty space on both sides (the .sidebar-content 12px padding).
Source-guard test tests/sidebarWidth.test.cjs.
Thanks to xet7 !
The #6465 per-list-header inline Add List composer (addListInline) had been
reduced to just a title input, dropping the options the old addListForm had.
Restore them:
- the "Add after which list" position <select>, listing the swimlane lists and
pre-selecting the list whose header button opened the composer; submit reads
it for afterListId and derives nextListId from the following option so the new
list is inserted between them (falls back to the header target for the empty
board case).
- the "or template" link (js-list-template) to create a list from a template.
Helpers swimlaneLists()/isDefaultAfterList() added; createListAfter already
accepts nextListId. Source-guard test tests/addListComposerOptions.test.cjs.
Thanks to csonkaoszimt and xet7 !
Fixes#6465.
Add the two new Member Settings keys (submit-on-enter, submit-on-enter-
description) to every language file in imports/i18n/data/, translated into each
language and inserted after show-desktop-drag-handles. English-variant locales
(en-GB, en_AU, ...) carry the English text; each real language matches its own
terminology, and the keyboard-key tokens Enter, Shift+Enter and Ctrl/Cmd+Enter
are kept verbatim. All 154 files JSON-validated; value-only additions.
#4236 made every multi-line editor submit only on Ctrl/Cmd+Enter (plain Enter
= newline) so titles could be multi-line, but that removed the fast
Enter-to-save title workflow some users rely on (v10 email feedback). Add a
per-user preference in the Member Settings (Change Settings) popup, saved to
profile.submitOnEnter and OFF by default: when on, plain Enter submits the card
title, description and other inlined forms, and Shift+Enter inserts a newline;
when off, behaviour is unchanged (Ctrl/Cmd+Enter saves).
The rule stays in the single pure isSubmitKey(event, {submitOnEnter}); the card
title, the card-description override and the shared client/lib/inlinedform.js
all route through it and read the preference from the current user. New toggle
+ helper + toggleSubmitOnEnter method + schema field, i18n (en, fi), and
editorSubmitKey.test.cjs extended with positive + negative opt-in cases.
Thanks to xet7 !
Related to #4236.
mongo 3.x mongoexport emits non-finite doubles as the bare tokens NaN,
Infinity, +Infinity and -Infinity, which are not valid JSON, so EJSON.parse
threw ("Unexpected token N/+") and migrate-mongo3-to-ferretdb.mjs dropped the
WHOLE document — leaving boards/cards missing after an otherwise "successful"
migration. sanitizeNonFinite() now rewrites those bare tokens, only outside
string literals, to the canonical EJSON v2 double form {"$numberDouble":"..."}
that EJSON.parse accepts, so the document migrates instead of being lost.
Strings that merely contain "NaN"/"Infinity" and ordinary negative numbers are
left untouched. Test tests/migrateNonFinite.test.cjs (with negative cases).
Thanks to Nissulya and xet7 !
Fixes#6481.
Rewrite the v10.00 section to match the final implementation and group ALL 101
commits in the release under their own headings (each with commit links):
- Corrected "done differently" cases: Change Color is visible grouped swatches
(not the initial two-level dropdowns); Font is font-name + size buttons with
immediate apply (not dropdowns); the board-header "icons only" change was
reverted so button texts stay.
- Fixed the Home board entry: it is set via the All Boards Multi-Selection
"Selected:" home action and the after-login redirect runs on all deployments,
so it is available, NOT disabled and NOT Sandstorm-only (an earlier draft
wrongly said the UI was disabled).
- Every commit since v9.99 is now listed once, grouped by feature/fix area.
Rename .github/workflows/playwright.yml -> playwright.yml.disabled so GitHub
Actions no longer runs it (only .yml/.yaml files in .github/workflows are
executed). Reversible by renaming back. NOTE: this workflow also contained the
Meteor unit-tests job and a Puppeteer regression job, so those stop running too.
The script lives in releases/translations/, so the repo root is two levels up
(../..), not one. With a single .. it landed in releases/ and looked for ../tx
at wekan/tx instead of the sibling ../tx, aborting with "tx not found". Match
the cd "$(dirname "$0")/../.." pattern used by the other scripts here.
The .tx config maps Transifex "war" -> local wa-RR.i18n.json, i.e. wa-RR is
Waray/Winaray (a Philippine language), NOT a regional variant of Walloon (wa).
An earlier seed wrongly copied Walloon content into it. Retranslate the file
fresh from English into Waray (2191 strings); placeholders/brand names
preserved, key set unchanged, JSON validated.
- Register Wu Chinese (wuu-Hans): it had a data file but no languages.js
entry, so it was neither browser-detectable nor shown in Change Language.
- Add wuu -> wuu-Hans to LANGUAGE_ALIASES so a bare "wuu" browser locale
resolves (mirrors zh -> zh-Hans).
- Fix display names that were in the wrong script for their (Latin) content:
Wolof "ولوفل" -> "Wolof"; Malay "بهاس ملايو" -> "Bahasa Melayu" (+ Malaysia).
km_KH/ru_RU are symlinks to km-KH/ru-RU, already covered. Every data file is
now registered, so all are browser-detectable and visible in the popup.
Fresh translations: vi, uz, uz-AR (Arabic-script Uzbek), ve (Venda), ve-CC
(Venetian), ve-PP (Vepsian), vo (Volapuk), wa (Walloon), wo (Wolof), xh
(Xhosa), yi (Yiddish), yo (Yoruba), zgh (Tamazight/Tifinagh), zu (Zulu).
Seeded variants uz-UZ/uz-LA, vi-VN, wa-RR, zu-ZA from bases. Completes the
full 153-language set. Placeholders/brand names preserved; JSON validated.
zh.i18n.json existed but had no entry in the languages registry, so a browser
reporting bare "zh" could not auto-detect it and it was missing from the Change
Language list. Add it (code zh, name 中文). The other two unregistered data
files (km_KH, ru_RU) are underscore duplicates already covered by the existing
km-KH / ru-RU entries, whose tag is the underscore form.
Seed Mandarin/Wu/Cantonese (cmn, wuu-Hans, yue_CN) from zh-CN, Japanese-Hiragana
locale (ja-HI) from ja, West Flemish (vl-SS) from nl, and Moroccan Arabic (ary)
from ar as machine-quality baselines sharing the written form, for the community
to refine. Placeholders preserved; JSON validated. 4074 strings.
Fill previously-untranslated UI strings in de, fr, es, it, nl, ru, pl, uk, cs,
ja, ko, zh-CN, tr, ar, pt. Each language matches its existing file terminology
as a glossary plus standard Kanban terms; product/brand names, acronyms, env
vars, console commands, placeholders (__var__, %s, {{..}}) and markup preserved
verbatim. Value-only changes; every file JSON-validated.
de 524, fr 617, es 917, it 938, nl 458, ru 974, pl 1037, uk 895, cs 1108,
ja 926, ko 850, zh-CN 929, tr 1059, ar 1145, pt 500 strings.
Fill previously-untranslated UI strings in the five near-complete languages,
matching each file existing terminology as a glossary and standard Kanban
terms (board, list, card, swimlane, label, checklist, theme, font, ...).
Product/brand names, acronyms, env vars, placeholders (__var__, %s, {{..}})
and markup preserved verbatim. Value-only changes; JSON validated.
zh-TW 29, pt-BR 28, da 159, he 262, sv 382 strings.
Pushes the English source, then force-pushes every language translation to
Transifex in one run (../tx push -s; ../tx push -t -f). -f is required or the
Go tx CLI skips languages whose local file is not newer than the server copy.
Warns that it overwrites newer community translations, so pull first if needed.
Translate the 21 previously-English strings in fi.i18n.json: the disable-*
and anonymize-* import/export/activities/notifications/watch admin feature
labels and descriptions, plus impersonation report title, impersonated user
and reason. Terminology follows existing Finnish strings (seuraaminen,
toimet, profiilikuva, tuonti/vienti, esiintyä käyttäjänä).
Below the "Multi-Selection is on" button a "Selected:" row now offers two
actions on the multi-selected boards:
- star icon: stars every selected board (sets them as Starred).
- home icon: sets the first selected board as the Home board (opened after
login) via the existing toggleDefaultBoard method + router redirect, which
brings the previously hidden Home-board feature back into use.
The Home board also always shows FIRST in the Starred list (even when it is
not itself starred), badged with a home icon centred at the top of its tile.
- Search boards box is now ~half width (300px); the input flexes to fill it.
- "Click checkboxes to select boards" hint moved out of the path title and
stacked directly below the "Multi-Selection is on" button (own column).
- Folder icon and the menu title (e.g. "Remaining") are grouped so the title
always sits to the RIGHT of the icon instead of wrapping below it.
The Filter by Unread / View All / Delete All Notifications item icons
(envelope, copy, trash, check) were faint; force the .menu-icon and .check-icon
(and their i.fa) to black.
The X dropped below the header because a global `.close { position: absolute;
top: 5px }` rule (boardBody.css) applied once my rule stopped setting position.
Set position: static on the drawer .close so it stays a flex item and aligns
with the Notifications title at the right edge of the header row.
- The drawer and its header are now full width (100vw) instead of 400px.
- Rebuild the header as a flex row (hamburger left, title centre via flex:1, X
right) instead of fragile absolute positioning, so the X is aligned with the
Notifications title at the right edge (was sitting too low).
- Force the hamburger and X to black with !important (they were inheriting the
themed header white link colour), overriding the surrounding themed bar.
- The X close button is now black, moved up (top: 8px, aligned with the
"Notifications" title instead of vertically centred lower) and to the far
right (inset-inline-end: 4px).
- The left hamburger menu toggle is black (was #333).
The member-menu "Notifications" item and its js-notifications-drawer-toggle
handler toggled the same notifications drawer as the header bell icon
(notifications.js), so it was a duplicate. Remove the menu entry and its
now-unused handler; the header bell is unchanged.
The js-new-search button clears the search (empties the input + query), so it
is a Clear button. Replace its broom icon with the text of the existing
trello-clear-job translation (en "Clear" / fi "Tyhjennä") and use it for the
aria-label too.
The global-search button hardcoded belize #216694 (inline !important styles +
.board-color-belize CSS), ignoring the theme. Make it a .primary type="submit"
button (safe: the search form has onsubmit="return false") so it uses the
theme override colour via the existing button[type=submit].primary rules
(default blue, or the board/global theme), and remove the hardcoded belize
styles.
The theme override colours .primary buttons via `button[type=submit].primary`
(board-color-* and custom-theme rules). A <button> without an explicit type
attribute does not match [type=submit] in CSS (though it already behaves as
submit), so the archive Restore/Delete buttons kept the default blue. Add
type="submit" (no behaviour change) so they match the theme rules and use the
global theme override colour (named or custom).
The header bars have a higher z-index than #modal, so the archive panel top
(and the close X) was hidden under the top header bar. Offset the archive
modal content 96px from the top (clears both the quick-access and board header
bars) and extend to the window bottom via min-height calc(100vh - 106px).
The archive modal used the default .modal-content (500px, margin: 5vh auto),
so archived boards were cramped and the panel stopped short of the window
bottom. Target the archive modal (the only one containing .archived-lists) and
make it 96vw wide with no bottom margin + min-height calc(100vh - 2vh) so it
reaches the bottom of the browser window; each archived board is a full-width
row.
Add the .primary class to both "Upload an avatar" buttons so they use the
theme primary-button style (default #005377 blue background + white text,
overridden by the board/global theme color) instead of the plain grey/black
default button.
Give .js-reset-text-color / .js-reset-bg-color a button appearance (border,
padding, background, hover) with a dimmed disabled state, matching the font/
size buttons.
Redesign the Font popup:
- Font: one button per installed font, each shown IN ITS OWN font (via inline
style), plus a Default button. Clicking a font applies it immediately.
- Size: a row of buttons ordered by percent — smaller on the left, 100%
(Default) in the middle, larger on the right. Clicking a size applies it
immediately.
- Colors: the text/background color wheels now apply immediately on change /
reset. Removed the Save button (everything applies on click).
New .ui-font-btn / .ui-font-size-btn styling (with .active) in labels.css.
Tests updated in tests/uiFonts.test.cjs.
Widen the language popup responsively (width: min(90vw, 1100px), max-width:
90vw) and lay the list out as an auto-filling grid (repeat(auto-fill,
minmax(170px, 1fr))) so as many languages as possible are visible at once on
wide windows, collapsing to a single column when narrow.
Guarded by tests/changeLanguageColumns.test.cjs.
- Revert the unconditional hiding of board-header button text labels (Private,
Muted, Sort, Filter, ...): they show again at normal widths. The pre-existing
mobile-only (max-width:800px, #6419) icons-only rule is untouched.
- CHANGELOG Upcoming: add consolidated entries for the recent All Boards /
board-header layout polish, the Change Color swatches / immediate-apply /
applies-everywhere / popup title, the #4759 user-insert validator fix, and the
rebuild-wekan.sh CURRENT-IP fix; mark the #2220 home-board toggle as currently
disabled.
"+ Add Board" and "+ Add Template Container" share the .js-add-board .label
element, so add an .is-template-container class to the templates-menu variant
and give it padding 20/8/22/8 — 2px lower than "+ Add Board" (18/8/24/8) —
while keeping the same 42px total vertical padding so the tile height is
unchanged.
Shift the .js-add-board .label vertical padding (top 24->20, bottom 18->22)
so the "+ Add Board" / "+ Add Template Container" text sits 4px higher, while
keeping the same 42px total vertical padding so the grey tile stays the same
height as the board icons. Test now checks total vertical padding equality
(height) rather than an exact padding string.
The desktop board-handle had a dark rgba(0,0,0,0.4) background box; make it
transparent so only the drag-handle icon is visible. The hover highlight is
kept. Guarded in tests/addBoardTileHeight.test.cjs.
The desktop board-handle was top-centered (top:4px; left:50%; translateX);
move it to the right middle (top:50%; translateY(-50%); inset-inline-end),
matching the mobile/small-screen handle position. Guarded in
tests/addBoardTileHeight.test.cjs.
- All Boards path header: order is now Multi-Selection, then Sort, then Search
boards (Search moved to the right of Multi-Selection; Multi-Selection moved to
the left of Sort). Guarded in tests/addBoardTileHeight.test.cjs.
- Top header bar: swap the positions of the mobile/desktop toggle and the zoom
controls (mobile toggle now right after the logo, zoom later). Both kept as
ungated direct children (zoom is no longer hidden when the logo is hidden).
Make the board-header button text labels (Private, Muted, Sort, Filter,
Swimlanes, Multi-Selection, ...) always hidden (was only under a max-width
media query), so the header shows icons only. The board title and the star
count (.board-star-counter) are not button labels and stay.
Guarded in tests/headerHamburger.test.cjs.
The #6465 one-click board-settings cog (js-open-board-menu) sat just left of the
sidebar hamburger, duplicating Board Settings which is reachable from the right
sidebar. Remove the cog from boardHeader.jade, its now-dead click handler from
boardHeader.js, and the unused .js-open-board-menu header CSS rule. The sidebar
board-menu button (sidebar.jade/js) is unchanged, and the hamburger + separator
remain.
Guarded in tests/headerHamburger.test.cjs.
When the window is not wide enough, the 2nd header bar button labels (Private,
Muted, Sort, Multi-Selection, ...) wrapped to a second row. Add a max-width:
1200px media query that hides the .board-header-btn text spans (show icons
only), keeping the board title and the buttons on one line. The star count
(.board-star-counter) is kept.
Guarded in tests/headerHamburger.test.cjs.
Previously the sidebar hamburger sat 12px from the right edge (2px margin +
10px bar right padding), more than the ~8px gap to the right of the user name
in the top bar (.header-user-bar-name margin-inline-end: 8px). Remove the board
header bar right padding and give the hamburger margin-inline-end: 8px, so its
right-edge gap is the same small amount as the user name.
Guarded in tests/headerHamburger.test.cjs.
The hamburger used the general .board-header-btn margin: 0 12px, leaving a
button-sized empty gap on each side. Tighten its side margins to 2px (and the
preceding cog button right margin to 2px) so the hamburger sits snugly at the
right edge with no wasted space to its left or right.
Guarded in tests/headerHamburger.test.cjs.
The board header bar (Swimlanes + Lists views) used a float layout: the right
button group (which ends with the js-toggle-sidebar hamburger) was float:
inline-end. As the window width changed, the floated groups wrapped and the
hamburger drifted to the middle of the bar. Make #header-main-bar a flex row
(align-items:center, flex-wrap:wrap), make the button groups flex (their
buttons float is ignored inside a flex container), and pin the right group with
margin-inline-start:auto so it always hugs the right edge (or the right of its
row when wrapped).
Guarded by tests/headerHamburger.test.cjs.
Feedback fixes to the Select Color picker:
- Apply IMMEDIATELY on clicking a swatch (and when a custom-color wheel is
committed) via a shared applySelection(); removed the Save button/handler.
- Category titles (Flat/Clear/Dark/Special) are left-aligned and clear: both,
so they drop below the previous group swatches (which float: inline-start)
instead of the 2nd/3rd/4th title sitting mid-row.
- Remove the empty band above the first (Flat) title (first-child margin-top:0)
and tighten the Default row.
- Member Settings Change Color popup now has a header: added changeColorPopup-title
("Change Color" / fi "Vaihda väri"), matching Board Settings.
Tests updated in tests/themeColorPicker.test.cjs.
The dev-server CURRENT-IP options detected the IP with
ip a | grep noprefixroute | ... | grep 192.
which requires the noprefixroute flag AND a 192.x subnet. On hosts without
either (e.g. arm64 Ubuntu on a 10.x/172.x network) it returned empty, so
ROOT_URL became http://:3000 and Meteor crashed with "TypeError: Invalid URL".
Detect the primary IP subnet-agnostically via the default route
(ip route get 1.1.1.1 -> src), fall back to hostname -I, then to localhost so
the URL is always valid. macOS uses ipconfig getifaddr en0/en1 with a localhost
fallback. Applied to both CURRENT-IP dev-server options.
Remove the fa-home Home-board toggle from the board tiles (boardsList.jade),
its click handler and the isDefaultBoard tile helper (boardsList.js), so a
Home board can no longer be set from the All Boards page. The model helpers,
server toggleDefaultBoard method and the login redirect are left intact but
are no longer reachable from the UI. Test flips to guard the disabled state.
The All Boards button showed only an icon (span.emoji-icon > fa-check-square-o)
with the reset X as a sibling, while the Swimlanes View (boardHeader.jade)
shows the check icon + a "Multi-Selection" text label with the reset X nested
inside. Match the All Boards markup to the Swimlanes View (direct icon + text
label + nested reset with fa-times-thin), and add stopPropagation to the reset
handler so the now-nested X does not bubble to the activate handler and
immediately re-enable selection.
Guarded by tests/multiSelectionButton.test.cjs.
The .boards-path-header was a single-row flex (justify-content: space-between,
no flex-wrap) and .path-right (search box + Sort / Multi-Selection / Clear)
also did not wrap, so narrowing the window — especially with Multi-Selection
on, whose hint widens .path-left — pushed those buttons off/hid them. Add
flex-wrap: wrap to the bar, .path-left (min-width:0 so it can shrink; hint
wraps under the title) and .path-right (buttons wrap among themselves), so
everything drops to a second row and stays visible.
Guarded in tests/addBoardTileHeight.test.cjs.
The .board-list-header div (a leftover zoom-controls container) rendered
nothing but still reserved vertical space via margin: 1vh 0 2vh 0 + padding:
1vh 0 — an empty grey band above the boards layout, between the top and the
left menu / "My Boards" bar. Removed the empty element from boardsList.jade
and its now-unused CSS rule, so .boards-layout is the first child of .wrapper.
Guarded in tests/addBoardTileHeight.test.cjs.
The grey add-tile (.js-add-board .label, shared by both "+ Add Board" and
"+ Add Template Container") overrode min-height:100px, line-height:56px and
padding:36px 8px 32px 8px — taller than the #6465-thinned board tiles
(.board-list-item: min-height:72px, padding:24px 8px 18px 8px). Match the
board-tile box model so the grey background is the same height as a board icon.
Guarded by tests/addBoardTileHeight.test.cjs (asserts the add-tile min-height +
padding equal the board tile, and the old oversized values are gone).
Two fixes from feedback that picking clearblue "did not change" and the
dropdowns were hard to use:
1) The global theme override now wins EVERYWHERE, including board pages. Before,
the <body> autorun suppressed it whenever a board was open (onBoard gate), so
changing the color while viewing a board did nothing. Now a set global override
is applied regardless of board context, and #header / #header-quick-access
(header.jade) and .board-wrapper (boardBody.jade) prefer the global override
over the per-board color. Unset it to return to per-board colors. When no
global is set, an open board still exposes its own custom colors.
2) The picker no longer uses category/theme dropdowns (colors were invisible).
It now shows the actual color SWATCHES with their names, grouped by category,
with the category name as a header above each group. The flat/clear color
wheels still appear once such a color is selected; custom-capability is derived
from the selected color. customTheme.css styles the group labels.
Tests updated: themeColorPicker/globalThemeColor guards for grouped swatches and
the global-wins-everywhere behaviour.
Two fixes to the #6465 inline Add List composer:
1) Save button did nothing. The inline composer calls createListAfter WITHOUT
nextListId, but the server check() used Match.OneOf(String,null,undefined)
(not Match.Optional) for it. Meteor check throws "Match failed [400]" on a
MISSING object key unless the sub-pattern is Match.Optional, so every inline
add-list 400'd. The omittable params (swimlaneId/afterListId/nextListId/type)
are now Match.Optional, so callers may omit them.
2) Empty swimlane/board now shows a + button, and the create-list form appears
only after clicking it (a swimlane that already has lists keeps using the
per-list-header add-list button — no + button needed). The reveal is scoped
to the clicked swimlane via a wekan-add-list-empty Session flag, cleared on
save/close.
Tests: models/lib/createListParams.js + tests/createListParams.test.cjs mirror
the method's param contract (incl. Meteor's missing-key rule) with the exact
client shapes + negatives, and a source guard that the check uses Match.Optional;
tests/upcomingUiGuards.test.cjs gains guards for the empty-state + button reveal.
Wired into test:unit:node.
specs/13-swimlanes.e2e.js waited only 6s for the swimlane action .js-pop-over
to appear. Under the full parallel suite that occasionally exceeds 6s on
webkit (the popup opens fine, ~3s, when the test runs alone), so the test
flaked. Bump to 15s to match the suite standard popup-visibility wait; a
genuinely broken popup still fails.
The optional profile.uiTextColor / profile.uiTextBgColor schema fields ran
their custom() hex validator on EVERY user insert, including when the field
was absent. /^#..$/.test(undefined) is false, so the validator returned
"notAHexColor" and collection2 threw ValidationError for any user with no
custom color set — surfacing as a SyncedCron fatal unhandledRejection and
blocking user creation (seen in ../log test-server.log; also cascaded into
ECONNREFUSED e2e failures as the server destabilized).
Guard both custom() validators to return undefined when the value is unset
(undefined/null/empty), matching the existing list-color validator. Add a
source-guard test so the guard cannot silently regress.
Translate the strings added this cycle in fi.i18n.json, reusing existing
terminology (väri, taulu, lista, uimarata, fontti, teema, Oletus): the Select
Color theme categories, the Member Settings font / size / text + background
color pickers, the default-board tooltips, and the list-move confirmation.
Fixes theme-category-clear, which had been auto-translated to the verb
"Tyhjennä" (empty) instead of the theme sense "Kirkas". font-preview-text uses
the standard Finnish pangram so the preview shows ä/ö.
Restore the old "a grain opens straight into its board" behaviour as a
convenience, WITHOUT persisting anything. On the Sandstorm home route only:
- a saved Home board (explicitly chosen by the user) always wins -> redirect;
- else, once the boards subscription has loaded, exactly ONE board -> just
open it (nothing is saved);
- else (zero or many boards, no chosen Home board) -> stay on All Boards.
Choosing a Home board stays a separate, explicit action (the All Boards home
toggle, #2220) — the auto-open never writes it.
The redirect is reactive (Tracker.autorun over a boards subscription), so it
waits out Sandstorm asynchronous grain login (Meteor.userId lands late) and
board loading instead of firing once too early. Runs at most once per page
load, and only when isSandstorm.
- models/lib/sandstormAutoOpen.js: pure, unit-tested decideSandstormAutoOpen()
(+ tests/sandstormAutoOpen.test.cjs, wired into test:unit:node).
- config/router.js: startSandstormAutoOpen() reactive redirect, gated to
Sandstorm; non-Sandstorm keeps the existing one-shot default-board redirect.
The Font popup now has a color wheel for the text color and one for the text
background color, each with an Unset button to go back to default. Values are
free choices (native <input type=color>), validated server-side as #rrggbb
hex (models/lib/uiFonts isHexColor6) so only a strict hex ever reaches a CSS
value — no injection surface. An unset/invalid value clears that color.
- profile.uiTextColor / profile.uiTextBgColor schema (hex-validated) + getters;
setUiColors(textColor, bgColor) method ($set valid hex, $unset otherwise).
- changeFontPopup: two color wheels + reset buttons; live preview reflects
font, size, text color and background color.
- Applied UI-wide via --wekan-ui-text-color / --wekan-ui-bg-color CSS variables
+ has-ui-text-color / has-ui-bg-color body classes (uiFont.js + uiFont.css).
- i18n text-color / text-background-color; tests extended (hex + negatives +
source guards).
Part of #4759.
New "Font" entry in the member menu opens a popup with a dropdown of fonts
DETECTED as actually installed in the browser (no free typing) and a Font
size dropdown of sensible presets (Smaller..Largest, no typed numbers). Both
have a Default option that unsets the custom choice.
Security: font names and size keys are validated server-side against a
curated whitelist / preset list (models/lib/uiFonts.js), so only a known safe
font name and a preset percentage ever reach the DOM. Labels are plain text
(Blaze-escaped) — never HTML or markdown. No CSS-injection surface.
- models/lib/uiFonts.js: UI_FONTS whitelist + SAFE_FONT_RE + isKnownFont /
fontFamilyValue and UI_FONT_SIZES presets + isKnownFontSize / fontSizeValue.
- client/lib/fontDetector.js: canvas width-comparison detection of installed
fonts, filtered to the whitelist.
- profile.uiFont / profile.uiFontSize schema + getters; setUiFont /
setUiFontSize methods (validated, null/default unsets).
- changeFontPopup (font + size dropdowns, both with Default) wired in
userHeader.js; applied UI-wide via CSS variables in uiFont.js + uiFont.css
(marker body classes), wired into client/features/main.js + client/styles.js.
- i18n change-font/font/font-default/font-size(+presets); tests/uiFonts.test.cjs
(pure + negatives + source guards) wired into test:unit:node.
This is a Member Settings feature (not an Admin Panel option).
Fixes#4759.
Both Board Settings and Member Settings Change Color now use a shared
category -> theme two-level dropdown picker with custom color wheels for the
flat (1 color) and clear (2 colors, a color slide) categories; dark/special
are fixed. Custom colors are validated server-side as #rrggbb, stored in
board.customThemeColors / profile.globalThemeCustomColors, and applied as
CSS variables (--theme-accent / --theme-accent-2) consumed by customTheme.css
to recolor the header, primary buttons and sidebar button.
- client/components/main/themeColorPicker.{jade,js}: shared picker, scope
"board" or "global", reusing the #5514 native color wheel + themeCategories.
- board.setColor(color, custom) + setGlobalThemeColor(color, custom): validate
via isValidCustomColors (flat/clear + count + hex) before storing.
- boardChangeColorPopup and changeColorPopup now render the shared picker;
removed their old swatch-list helpers/events.
- globalThemeColor.js: apply custom colors as :root CSS variables (board own
colors on a board, else the user global override) + marker body classes;
customTheme.css consumes them.
- Wire globalThemeColor.js / themeColorPicker into client/features/main.js and
customTheme.css into client/styles.js. This also fixes globalThemeColor.js
never having been imported (so the #5778 override now actually loads).
- i18n theme / theme-category[-flat/clear/dark/special]; tests
themeColorPicker.test.cjs + updated globalThemeColor.test.cjs.
Fixes#5778.
Partition the ~19 board/global theme colors into flat / clear / dark /
special and define where custom colors are allowed (flat = 1 accent,
clear = 2 for a color slide, dark/special = fixed none). This is the shared
source of truth for the redesigned Select Color picker (two-level dropdowns
+ color wheel) used by both Board Settings and Member Settings.
- models/lib/themeCategories.js: THEME_CATEGORIES + categoryOf /
colorsInCategory / allowsCustomColor / customColorCount /
isValidCustomColors (validates category + count + #rrggbb hex).
- tests/themeCategories.test.cjs (wired into test:unit:node): behaviour +
negatives + a source guard that the partition exactly equals
config/const.js ALLOWED_BOARD_COLORS.
- docs/Theme/Theme.md: full design — categories, two-level dropdown UX,
custom-color rules, CSS-variable rendering plan, storage
(board.customThemeColors / profile.globalThemeCustomColors), and
server-side validation.
Completes the global per-user theme override (Member Menu / Change Color)
begun in the previous commit.
Fixes#5778.
A new "Change Color" entry in the member menu works like Board Settings /
Change Color, but is a per-user GLOBAL override saved to the profile
(profile.globalThemeColor). The chosen color theme applies to the whole UI —
All Boards, Search All Boards, Admin Panel, My Cards, etc. — via a
board-color-<name> class on <body> and the header, so a user can pick a dark
theme (dark/midnight/moderndark/exodark/cleandark) or any other theme
everywhere. The first popup entry clears the override.
- models/users.js: profile.globalThemeColor field + getGlobalThemeColor /
globalThemeColorClass / setGlobalThemeColor helpers.
- server/models/users.js: setGlobalThemeColor method, validated against
BOARD_COLORS (rejects unknown colors so no arbitrary CSS class is injected)
and auth-guarded; null/empty clears it.
- client/components/main/globalThemeColor.js: Tracker autorun that adds the
class to <body> on non-board pages; on a board the board own color wins, so
the global class is cleared there to avoid two themes clashing.
- header.jade: #header and #header-quick-access fall back to the user global
theme class when not on a board (covers the #header-specific color rules).
- Change Color menu entry + changeColorPopup (color swatches + clear option),
wired in userHeader.js.
- i18n change-color / theme-default; tests/globalThemeColor.test.cjs wired
into test:unit:node.
Deleting a list no longer destroys it. The list and its cards are marked
(deletedAt/deletedBy/deleteBatchId), hidden from the board, recorded as a
reversible delete in history, and restorable via lists.restore or Ctrl+Z.
This is the first slice of "no permanent delete in ordinary use": physical
removal is limited to GDPR/account erasure and a Global-Admin purge gated by
a new Admin Panel / Features / Delete "Enable permanent delete" toggle
(off by default).
- models/lib/softDelete.js: pure notDeleted/softDeleteSet/restoreModifier/
canPurge helpers (+ tests/softDelete.test.cjs, wired into test:unit:node).
softDeleteSet omits falsy actor/batch and restore uses $unset so no null is
ever written to a Date/String schema field.
- enablePermanentDelete feature flag (models/lib/featureFlags.js) + Settings
schema field.
- deletedAt/deletedBy/deleteBatchId schema fields on Lists and Cards
(optional, no null default -> absent means live).
- board/swimlane list render paths filter deletedAt: null.
- server/models/lists.js: shared softRemoveList() + lists.softRemove /
lists.restore / lists.purge (purge gated on canPurge = isAdmin && flag);
client delete handler and REST DELETE now soft-remove.
- userPositionHistory undo()/redo() handle actionType delete/restore via a
batch-consistent _applyDeleted() helper.
Design + planned rollout (other entities, Recycle Bin, admin Delete category
table with GDPR data classes) in docs/Features/Undo/Undo.md.
Every user-facing delete becomes a soft delete (deletedAt/deletedBy), making
deletions restorable and undoable (#1023). No permanent delete in ordinary
use: physical removal is limited to GDPR/account erasure and an explicit
Global-Admin purge gated behind Admin Panel / Features / Delete ->
"Enable permanent delete for Global Admin" (off by default). Covers scope
(soft vs exempt collections), the softRemove/notDeleted mechanism, cascade
via deleteBatchId, archived-vs-deleted distinction, undo/History integration,
and migration steps.
The activities publication only ships the most-recent `limit` activities and
the client pages them in via loadNextPage, so large boards stay fast without
deleting activity history. Document this so the request is closeable.
Fixes#2539.
The 'Filter by date -> Overdue' and 'list disappears in swimlanes' fixes were
reported originally by email, not as GitHub issues - #6483 and #6484 do not exist
(404). Replace the dead issue links in their Upcoming entries with '(reported by
email)'. The fixes themselves are unchanged.
Thanks to xet7.
Adds tests (with negative cases) for the Upcoming changes that previously lacked
them:
- tests/defaultBoard.test.cjs (#2220): behavioural toggle/decision logic (set,
unset the current default, switch to a different board; negatives: nothing is
the default when unset, B is not the default when A is) + source guards that
the schema, model + server toggleDefaultBoard, once-per-session router redirect,
and board-tile toggle are all wired.
- tests/upcomingUiGuards.test.cjs: source guards for the #6465 Add List header
button + inline composer (leading column replaced by empty-state gating),
minicard white-space (min-height:0) and swimlane-header zoom clip
(overflow:visible/height:auto), and the #6478 touch confirmation before a
cross-swimlane list move (gated on touch/small screen; declining aborts).
The other Upcoming changes already had tests (filterDateNull, listMoveSwimlane,
cardDragSwimlaneScrollRefresh, popupAfterConfirm, undoRedoSelection,
listWidthDefaults, ferretdb* in the FerretDB repo).
Fixes#2220. Fixes#6465. Fixes#6478. Fixes#6479.
Thanks to xet7.
On the All Boards page each board tile gets a home (house) toggle next to the
star. Marking a board sets it as the user's default 'home' board; the next login
(or reload) lands on it instead of All Boards. Clicking again clears it.
- profile.defaultBoardId (per user) + getDefaultBoardId/isDefaultBoard/
toggleDefaultBoard model helpers + a toggleDefaultBoard Meteor method (mirrors
toggleBoardStar).
- home route redirects to the default board ONCE per session (so clicking All
Boards afterwards stays on the list; honoured again next login/reload); by id
so it works before the board subscription loads; graceful fallback if the board
is gone.
- board tile .js-set-default-board toggle + isDefaultBoard helper; i18n
set/unset-default-board-title.
Thanks to xet7.
Per request, the History design now records EVERY change a user makes (not just
card groups) in one append-only changeHistory store, and undo/redo becomes the
keyboard front-end to it (restore the current user's most recent change) rather
than a separate feature - superseding userPositionHistory.
Same table + restore is surfaced from many menus, each just a scope filter over
the one store: card group, whole card, Member settings (per-user), Board Settings
(per-board), Swimlane menu, List menu, and any future entity menu. Scopes nest
(card in list in swimlane in board) via id-column ORs. Added a scoped-views
section, the scope/scopeId page() params, per-scope permissions, and updated the
phasing (migrate position undo/redo onto changeHistory first). Undo.md now points
at History.md as the source of truth for the unified direction.
Thanks to xet7.
docs/Features/Undo/Undo.md documents the #6478 feature: position-move undo/redo
(card/list/swimlane) via userPositionHistory with an undone/undoneAt redo stack,
undoLast/redoLast methods, Ctrl+Z/Ctrl+Y bindings, and the touch confirmation for
cross-swimlane list moves. Records the inert-recording bug (collection referenced
as an un-imported global), the write/read wiring, retention, v1 limitations
(positions only; content undo is the separate History feature) and an extension
checklist.
Thanks to xet7.
Detailed design doc at docs/Features/History/History.md for the requested card
details 'History' feature: per-group history popup with a searchable, paginated
(current page only), per-contributor change table and restore.
Key point: WeKan's Activities log records what happened but NOT before/after
values, so restore needs a new append-only cardGroupHistory content-versioning
collection - the doc specifies the model, write/read (paginated+searchable+
per-user) methods, the 2-pane UI (History + contributor avatars | table with
select/change-type/content/datetime, search+pagination+restore bar), RTL
mirroring, restore semantics (re-logged to both source and restorer; history is
append-only), security, and a phased rollout starting with Description.
Thanks to xet7.
Swimlanes/Lists views no longer render a permanent Add List composer column.
Each list header now has a far-right add-list button; clicking it opens the Add
List composer as a column immediately AFTER that list in the DOM - which appears
to the right of the list in LTR and to the left in RTL (the lists lane is a flex
row that mirrors under dir=rtl). An empty swimlane/board shows the composer at the
start so the first list can still be added.
- new always-open addListInline template (title input + save + close), submit ->
createListAfter (afterListId = the clicked list, swimlaneId = the displayed
swimlane recorded from the DOM by the header button).
- Session 'wekan-add-list-after'/'wekan-add-list-swimlane' drive which list the
composer opens after; isAddListAfter/swimlaneHasNoLists/boardHasNoLists helpers.
- leading +addListForm removed from the non-mini swimlane and listsGroup
branches; mini-screen path unchanged.
First cut - desktop/main views; needs live verification of styling, RTL and the
empty-board case.
Thanks to csonkaoszimt (report) and xet7.
A user accidentally dragged a list into another swimlane on mobile (merging it
with an existing list) and spent ~15 min recovering - no confirmation, no undo.
Undo/Redo: the userPositionHistory collection modelled this but was NOT actually
recording (trackChange guarded on an un-imported global) and had no redo or key
bindings. Now:
- list moves are recorded in updateListSort (import UserPositionHistory so the
guard passes); card moves already had the call.
- add a symmetric redo() model method + an undone/undoneAt redo stack; add
userPositionHistory.undoLast/redoLast methods (a new action clears the redo
stack via trackChange).
- wire Ctrl+Z / Ctrl+Y (and Cmd variants) in client/lib/keyboard.js; disabled
inside inputs/textareas so native text undo is unaffected.
- pure selection logic models/lib/undoRedoSelection.js + tests.
Confirmation: on touch / small screens, moving a list to a DIFFERENT swimlane
(which re-homes every card) now asks for confirmation; a decline reverts the
drag. Same-swimlane reordering is unaffected.
Thanks to mueschel (report) and xet7.
Clicking a .js-confirm button silently did nothing. Popup.afterConfirm() stashed
the pending action as a field on the Blaze DATA CONTEXT and the confirm button
read it back as this.__afterConfirmAction. But the context is a
ReactiveCache/Minimongo document (a board member sub-doc), and Blaze re-renders
the confirmation popup with a fresh/immutable copy of that context, so the field
was gone by click time - so every afterConfirm dialog (remove member from board,
etc.) no-oped.
Store the action on the Popup INSTANCE (Popup._afterConfirmAction) instead, which
survives the re-render; it is still invoked with the confirmation popup's own data
context as this, so this.userId keeps working. The .js-confirm handler also guards
against a missing action instead of throwing. Test tests/popupAfterConfirm.test.cjs
with a negative case reproducing the old context-mutation failure.
Thanks to mueschel (report) and xet7.
Dragging a card from one swimlane to the SAME list in another swimlane dropped
it back in the source swimlane, especially with long overflowing lists. The card
sortable's sort handler auto-scrolls the board (#443) via .js-lists scrollLeft /
.board-canvas scrollTop, but jQuery UI sortable caches container/item geometry at
drag start and only re-caches on its own placeholder moves - never on our manual
scroll. Long lists are exactly what triggers auto-scroll, so the drop resolved
against a stale geometry map and the stop handler's ui.item.parents('.swimlane')
persisted the wrong swimlane.
Re-cache positions with sortable('refreshPositions') whenever the sort handler
actually scrolled - complementing the #2769 DOM-mutation refresh in listBody.js,
which does not fire on scroll. Source-guard test
tests/cardDragSwimlaneScrollRefresh.test.cjs.
Thanks to mueschel (report) and xet7.
The #6465 density change lowered MIN_LIST_WIDTH 270->200 and the default
272->220, but specs/38-fixed-list-width.e2e.js still asserted the old 270 floor:
setFixedListWidth(200) was expected to be REJECTED (it is now valid), and the
anonymous default was expected to be 272. This failed on chromium/firefox/webkit.
Use 150 as the too-small value (below the new 200 floor), update the client MIN
mirror to 200 and the default to 220, and add a POSITIVE case that a width of
210 (>=200 but below the old 270) is now accepted.
Thanks to xet7.
v9.99 was released with the LDAP connection-leak fix, the bundled-FerretDB pool
note and the snap #6476 wait-loop diagnostics. Everything committed after the
v9.99 bump - the QEMU snap build, the #6465 UI density/minicard/dock/swimlane
changes, the #6483 date-filter fix, the #6484 list-move fix, and the #6476
root-cause (FerretDB orphaned-table crash loop) - now sits under a new
# Upcoming section above v9.99 instead of being backdated into v9.99.
Thanks to xet7.
Updates the #6483 note: label ($in), title ($regex) AND date range
($gt/$gte/$lt/$lte) filters are all now pushed down to SQLite in the bundled
FerretDB, so none of them full-scan the board. Dates use SQLite's ->> accessor
for numeric comparison of the stored millis, verified end-to-end.
Thanks to xet7.
Notes that the filter slowness flagged earlier is addressed in the bundled
FerretDB, which now pushes {labelIds: {$in: [...]}} and literal {title: {$regex}}
down to SQLite instead of scanning + matching every card's sjson in Go.
Thanks to xet7.
At e.g. 80% zoom (transform: scale on .board-wrapper) the gray swimlane header
(.swimlane-header) looked cut off: it had overflow: hidden with a fixed
min-height, so once the scaled layout rounded, the bar/text was sliced. Use
overflow: visible + height: auto (keeping the min-height floor) so the header
grows to fit and cannot clip vertically; short swimlane names are unaffected and
a long name wraps instead of being cut.
Speculative CSS fix - verify in the running app at 80% (and check 50%/125%/200%).
Thanks to xet7.
Operator logs (uusijani, a1bert01) showed FerretDB was listening and WeKan
connected, then a startup SyncedCron upsert hit FerretDB error
'table accountslockout.connections_<hash> already exists', which became an
unhandledRejection and exited the process; systemd crash-looped it so the HTTP
port never came up. The real fix is in the bundled FerretDB (collectionCreate
now uses CREATE TABLE/INDEX IF NOT EXISTS to re-adopt an orphaned table). The
snap wait-loop timeout/diagnostics remain useful for the separate 'FerretDB
genuinely not ready' case.
Thanks to xet7.
Several users reported 9.x wastes space vs the older 6.09 layout. Tighten three
density defaults (all overridable; user customizations untouched):
- List width default 272 -> 220px (models/lib/listWidth.js, models/lists.js),
minimum 270 -> 200px here and in the server check (server/models/users.js).
Lists already render the same width by default (resolveListWidth) on private
and public boards; now narrower so more fit. Test updated.
- Board tiles (All Boards page): min-height 100 -> 72px, vertical padding
36/32 -> 24/18px (boardsList.css).
- Card-detail right dock max-width 800 -> 520px (and the wide-screen centred
variant 600 -> 520px) in cardDetails.css, so the opened card no longer takes
~1/4 of the screen.
Thanks to xet7.
A board-wide list has swimlaneId === null and renders under every swimlane. The
list-drop handler computed
isDifferentSwimlane = targetSwimlaneId && targetSwimlaneId !== originalSwimlaneId
but targetSwimlaneId is always the swimlane the list is shown under, and
originalSwimlaneId is null for a board-wide list, so ANY small drag made this
true - it set list.swimlaneId AND moved every card in the list to that one
swimlane, so the list vanished from all other swimlanes (recoverable only by
restoring a backup).
Also require originalSwimlaneId: board-wide lists stay board-wide on a reorder,
while a genuinely swimlane-scoped list can still be moved between swimlanes. Test
tests/listMoveSwimlane.test.cjs, with a negative control that the old target-only
condition rebound a board-wide list.
Thanks to xet7.
Cards without a date store the field as null (that is what the sidebar's noDate
filter matches: {dueAt: null}). The comparison filters build {$lte: now}
(Overdue/past) and {$gte, $lte} (today/this/next week), and $lte MATCHES null
under both FerretDB and minimongo - null sorts before any date and neither
implements MongoDB type-bracketing - so Overdue selected every dateless card.
DateFilter._getMongoSelector now adds $ne: null to any comparison selector so
only real dates match; the noDate filter (a bare null) is unchanged. Test
tests/filterDateNull.test.cjs, with a negative control proving the old bare
{$lte: now} matched null.
The reported filter SLOWNESS and the title/label over-matching are separate
(FerretDB scanning $regex/$in/range queries not pushed down to SQLite) and need
live reproduction.
Thanks to xet7.
The minicard title renders inside a .viewer, which inherited the global
.viewer { min-height: 2.5vh } (client/components/main/layouts.css). On tall
screens that reserved a tall empty band beneath a one-line title, so a large
part of every minicard was blank and fewer cards fit on screen. The minicard
title .viewer now sets min-height: 0 (the same override already applied to the
label .viewer), so a minicard collapses to fit its content.
Thanks to xet7.
The Launchpad 'snapcraft remote-build' legs for ppc64el and s390x ended in
Launchpad state 'Stopped' with no snap produced, yet remote-build still exited 0;
the job's name-only success check let an empty/stale file through and the upload
died with ''wekan_<v>_<arch>.snap' is not a valid file' (exit 64). Build them
instead with docker/setup-qemu-action + diddlesnaps/snapcraft-multiarch-action on
a normal runner - fast, because the snap is bundle-centric (the wekan part only
downloads the prebuilt wekan-<version>-<arch>.zip and repackages it, no native
compilation).
riscv64 stays on Launchpad (the QEMU snap action does not support it) but now has
timeout-minutes: 180 so a stuck build fails with a clear message instead of
GitHub's silent 6-hour cancel.
Thanks to xet7.
With database=ferretdb, snap-src/bin/wekan-control waits for FerretDB to accept
connections before starting node - WeKan does not open its HTTP port until the
database answers. That wait loop had no timeout and no diagnostics, so if
FerretDB never started listening (crashed or arch-incompatible per-arch binary,
locked/corrupt SQLite, or the service left disabled by a failed migration
hand-off), WeKan blocked there forever: the service showed active but the port
never opened and the only symptom was a silent 'FerretDB not ready yet' loop.
uusijani's wekan.log stopped right after the startup env dump, confirming
control never reached node main.js.
Mirror the MongoDB branch: after WEKAN_DB_WAIT_TIMEOUT seconds (default 120,
overridable) print an actionable hint once, then keep retrying - pointing to
'snap logs <snap>.ferretdb', naming the SQLite dir to check for locks/corruption,
the arch-mismatch case, the snap start --enable recovery, and the
'snap set <snap> database=mongodb' fallback. Regression test
tests/ferretdbWaitTimeout.test.cjs, including a negative guard that the wait is
not a silent unbounded loop again.
Thanks to uusijani (report) and xet7 (fix).
tx pull -f fills any string untranslated on Transifex with the English source, so
languages whose translations live only in git silently revert to English on every
pull. Make the pull self-heal, and fix the push helpers so restored translations
actually upload.
- pull-translations.sh: after the pull, for each language file whose changes are
ENTIRELY reverts, git checkout HEAD -- <file> to restore the committed
translations and force-push them back (../tx push -t -l <lang> -f). Files that
also carry a real new/updated translation from Transifex are NOT auto-healed
(a whole-file checkout would discard it) and are left for manual handling.
- report-english-regressions.mjs: add a machine-readable --files mode and an
otherChanges classifier, so only pure-revert files are offered for auto-heal;
the human report tags mixed files.
- push-translation.sh: add -f (without it the Go tx CLI skips a language whenever
the local file is not newer than the server copy - push.go shouldSkipPush - so
a freshly reverted file uploads nothing), plus a usage guard.
- push-copy-en-gb-translation.sh (new): copy en.i18n.json to en-GB.i18n.json
verbatim and force-push it as the en_GB translation, so British English shows
as translated instead of reverting to the English source on each pull.
Thanks to xet7.
Operators reported that after an update WeKan "dies really quickly", restarts
did not help, and it "kills our openldap server with too many open connections";
others saw logins hang for minutes then fail with "Must be logged in". Every
LDAP login attempt (loginHandler.js) and every background sync tick (sync.js)
created a new LDAP() and connect()ed but NEVER called disconnect() on any path,
so each attempt - including every failed login and every one-minute sync tick -
leaked a socket to the LDAP/AD server until it hit its connection limit and
started refusing connections, taking it and all WeKan logins down.
Guarantee release on every exit path: a shared runWithLdapDisconnect() helper
(connectionGuard.js) disconnects in a finally; the login handler runs its whole
flow through it; background sync() disconnects in a finally; importNewUsers()
disconnects only the connection it owns; and LDAP.disconnect() is a safe no-op
when connect() was never reached. Adds behavioural + negative + source-guard
tests (tests/ldapConnectionRelease.test.cjs, wired into test:unit:node).
Also bumps the bundled FerretDB whose SQLite pool no longer caps MaxOpenConns
at 16 (that starved WeKan's cursor load: minutes-long board loads, failed
logins).
Thanks to xet7.
Document the two GitHub CodeQL code scanning fixes already committed
(alerts #423 js/incomplete-sanitization and #422
js/biased-cryptographic-random) in a new Upcoming section above v9.97,
linked to the wekan.fi Hall of Fame entries.
Thanks to GitHub CodeQL and xet7.
256 is not a multiple of the 55-character id alphabet, so the plain
byte % 55 mapping skewed generated document ids toward the first
characters. randomId now uses rejection sampling: bytes at or above the
largest multiple of the alphabet size (220) are discarded and resampled,
so every character is equally likely. Ids stay Meteor-style 17-char and
exact-length for custom lengths. Resolves code scanning alert #422.
Tests: tests/schemaUpgradeSteps.test.cjs gains a rejection-sampling
guard (negative case pins that out-of-range bytes are never wrapped).
Thanks to xet7.
The CSS-declaration-to-RegExp conversion escaped only parentheses;
escape the full regex metacharacter set (including backslash) instead.
Resolves code scanning alert #423. Test-only, fixed input list, but the
complete escape is correct and matches the pattern already used in
tests/archiveLinkGrouping.test.cjs.
Thanks to xet7.
Every deletion path (admin removeUser method, self-service account
delete, DELETE /api/users/:userId) removed only the users document,
leaving dangling references everywhere: empty-avatar board members that
could not be removed, stale card members/assignees/watchers, orphaned
avatar files - reproducible for 8 years and reopened in 2025. A
server-only Users.after.remove collection hook now prunes
boards.members/watchers (object-shaped, $pull by userId),
cards.members/assignees/watchers and lists.watchers (string arrays), and
the user's Avatars files, on EVERY path that removes a user; a cleanup
failure can never break the deletion itself. Activities and comments are
deliberately preserved for history - their rendering is already
null-guarded (270eacb20, Playwright-verified).
Tests: tests/userDeletionCleanup.test.cjs (6, positive and negative,
end-to-end against a fake database).
Thanks to chotaire and xet7.
Drag start hid every list's "+ Add Card" composer link with
display: none, collapsing its row: lists shrank, auto-height swimlanes
shrank, and every swimlane below jumped up about one row (and back down
on drop), moving the drop target under the cursor mid-drag. The root
cause was proven by frame-diffing the issue's own GIF: the three largest
frame discontinuities are exactly drag start and drop, showing the
composer row vanish and the next swimlane header shift ~23px. The
composer now hides with visibility: hidden, preserving its layout box;
checked multi-selection cards keep display: none intentionally (the drag
payload previews the post-drop list).
Tests: tests/swimlaneDragJump.test.cjs (8, positive and negative,
including a guard that flags any return of the layout-collapsing rule).
Thanks to gerroon and xet7.
off-screen list.
The horizontal auto-scroll in the card sortable targeted .board-canvas,
which stopped overflowing horizontally when the swimlane layout made the
.js-lists lane the horizontal scroller - scrollLeftMax was always 0, the
guard compared 0 < 0 and never fired, and ui.helper[0].offsetLeft -= 15
assigned a read-only property. Edge-proximity auto-scroll now drives the
lane actually under the pointer (axis-agnostic, clamped, overshoot-safe
helpers in imports/lib/boardAutoScroll.js), with vertical scrolling kept
on the board canvas.
Tests: tests/boardAutoScroll.test.cjs (15, positive and negative,
including a reproduction that the old no-overflow target can never
scroll).
Closes#603: obsolete - the stale-drop-target cause was removed by
d887e553c (perfect-scrollbar removal, native list scrolling),
ed8471be9 (sortable auto-scroll re-enabled) and jQuery UI 1.14.2, whose
sortable resolves insertion neighbours with live offsets on every
mousemove, so a scrolled target list cannot desynchronize drop targets.
Thanks to anhenghuang, AlexanderS and xet7.
Sandstorm username races.
- #2345: the Card Title Filter is now SAVED by every board trigger
builder (a trigger doc missing the field could never satisfy the
matcher's $in - those rules fired for nothing), SHOWN in the rule
details, and ENFORCED for archive/restore triggers by resolving the
title from the card when the activity lacks it; legacy field-less
triggers keep matching; the filter popup prefills its current value.
- #2674: rules created via POST/PUT /api/boards/:boardId/rules never
fired - missing matching fields are now normalized to '*' wildcards
and trigger/action types validated; the addMember/removeMember rule
actions no longer crash on unresolvable usernames or member-less
cards and their writes are awaited. New docs/API/Rules.md (endpoints,
matching fields, wildcard semantics, the exact two-rule
add-on-move-to/remove-on-move-from workflow), linked from REST-API.md;
api.py help now lists the rule commands with the same example.
- #574: Sandstorm unique-username generation probes case-insensitively
(anchored, regex-escaped) and retries the next number when a
concurrent insert wins the unique-index race, instead of aborting the
login hook with E11000.
Tests: tests/rulesCardTitleFilter.test.cjs (12),
tests/rulesApiTriggerNormalize.test.cjs (19),
tests/sandstormUsername.test.cjs (11) - positive and negative cases.
Thanks to InfoSec812, sfahrenholz, mitar and xet7.
Inviting by email derives the new user's username from the email local
part; a collision with an existing user (cats@foo.com then
cats@facebook.com) made Accounts.createUser throw Meteor's raw
"403 Username already exists", shown to the inviter as just "403". The
username now probes cats, cats1, cats2, ... to the first free variant
(bounded), and exhaustion raises the translated error-username-taken.
Tests: tests/inviteeUsername.test.cjs (11, positive and negative,
including the literal reported scenario).
Closes#804: already fixed - every popup is viewport-clamped with
internal scrolling since ac368de06 (#5667 geometry rewrite: maxHeight
from live viewport space, bounded flex layout) plus the 04eb8a8fb
(#6221) global 90vh clamp; the member picker inherits the shell, so
neither standalone nor the Sandstorm iframe can grow past the viewport.
Thanks to lemoer, ocdtrekkie and xet7.
The due-date picker configures defaultTime 17:00 (received/start/end use
now()), but an inverted guard in datePickerRendered applied it only when
the card ALREADY had a date - the one case where it is unnecessary - so
for dateless cards the time input stayed empty and submit stored a
hard-coded 12:00. Empty pickers now pre-fill with the configured
default, submit falls back to it, and existing dates keep their own
time. The 2018 AM/PM display/parse mismatch was already fixed by the
native HTML date/time inputs (79b94824e); week start already honors the
user preference.
Tests: tests/datePickerDefaultTime.test.cjs (10, positive and negative).
Thanks to Vlasterx, saschafoerster, suncobran and xet7.
- #2769: refresh drag geometry when the DOM changes mid-drag - cards no
longer drop into the wrong swimlane while someone adds a card.
- #1992: board import restores all five card date fields (and creator)
with fallbacks; receivedAt/endAt were never imported at all.
- #2292: archiving a swimlane archives its cards (mirroring lists);
restore brings back exactly the cards archived with it.
- #2494: client noCache card lookup returned a Promise since the
Meteor 3 port - multi-select board moves wrote sort: NaN everywhere.
- #1853: subtask "View it" falls back to the subtask's boardId when the
deposit board is not loaded, instead of silently doing nothing.
- #1554: restore the reactive dependency lost in 7673c77c5 so cards
added after board render accept sidebar label/member drops.
- #2306: "filter to selection" and every bulk action are board-scoped;
foreign-board cards can no longer be silently archived.
- #1437: new POST /users/logout API endpoint revokes the presented
resume token, or all tokens with {"all": true}.
All with positive+negative regression tests (see tests/*.test.cjs).
Closes#1389: already fixed - the standalone pencil edit button
(0cc63b810) plus the wrapped viewer (bf2b3b40c) guarantee an edit target
even when a full-width link fills the description.
Thanks to hever, Cactusbone, Vermeille, Vanclief, Miffe, IcedQuinn,
ppouliot, GhassenRjab and xet7.
Since 8c3ce4bb7 (2021) the "close the previous inlined form" call was a
silent no-op: the inlinedForm escape action registers with
enabledOnClick: false and EscapeActions.clickExecute skips such actions,
so clicking another checklist item left both edit forms open - and the
submit handlers find the template's FIRST textarea, so the wrong form's
text was saved over the submitted item. Subtasks reproduced the full
bug; the checklists workaround corrupted the shared open-form tracker so
Escape fell through and closed the whole card details pane. A pure state
manager (client/lib/inlinedFormManager.js) now enforces the single-open
invariant: opening a form closes the tracked previous one (popups
untouched, preserving the 2021 intent); close/destroy only reset the
tracker for the form they own.
Tests: tests/inlinedFormSingleOpen.test.cjs (9, positive and negative,
including the exact reported A->B->C repro).
Thanks to Beebo89 and xet7.
Two defects: the tokenizer flipped into regex mode on every '/' even
inside quoted strings, so a quoted date like '06/04/2020' broke
tokenizing and the whole filter silently no-opped; and date custom
fields store Date objects while the comparison selectors used strings
and parseInt - equality and ranges could never match, != matched every
card. Dates now parse per the user's date format (day-first formats
respected) into half-open Date-range selectors; non-date fields keep the
legacy selectors unchanged.
Tests: tests/advancedFilterDate.test.cjs (14, positive and negative).
Closes#2521: already fixed since v3.88 (9819c9f80) - the checklist
completed/uncompleted activity text was missing due to an activityType
name mismatch between model and template; the current unified activity
template, i18n keys and helpers render it correctly.
Thanks to k1ng440, ott29 and xet7.
addSubtaskCard inserted every subtask card with the constant sort -1,
leaving the whole list tied: a drop between two equal sorts computes a
zero increment, the move modifier is empty and Card.move() silently
discards it - the card snapped back, and a multi-selection drop wrote
the SAME sort to every selected card, permanently destroying their
relative order (the data-loss risk in the issue triage). Subtask cards
now append with a unique sort (max+1), and the sortable stop handler
detects degenerate gaps (ties/inversions) and repairs the siblings'
sorts to a strictly increasing order before recomputing the drop index;
healthy lists take the unchanged fast path.
Tests: tests/subtaskCardReorder.test.cjs (14, positive and negative,
including the exact issue scenario and a guard that the old
{base:-1, increment:0} result can never be produced again).
Thanks to jayki and xet7.
- #3453: publish the FULL subtask ancestor chain, not only direct
parents - the cross-board full-path label vanished after refresh.
- #3748 (defect half): skip unresolvable custom-field definitions on
linked cards - phantom empty rows and a template TypeError on every
card details render. The mirroring itself is by design: linked cards
are pointers; label/custom-field ids are board-scoped; name-based
inheritance is the copy feature, not the link feature.
- #3199: group each archived card with its own Restore/Delete links and
add a clear separator below the group (RTL-safe, theme-neutral).
- #3843: comment-editor uploads and the attachments popup now share one
null-safe meta builder, and tests pin that comment attachments list in
the card's Attachments section.
Closes#3748: mirroring is by design (see above); the only actionable
defect is fixed in this commit.
Closes#3378: already fixed - notification_cleanup moved off SyncedCron
to a guarded Meteor.setInterval singleton, and quave:synced-cron 2.4.0
handles the E11000 history collision that percolate 1.5.x missed.
Closes#3276: already fixed by d3625db75 - the spent-time badge helpers
now read the live Cards document reactively, so the overtime color flips
immediately; verified behaviorally against the real component.
Closes#3843: behavior verified present and now regression-locked.
Thanks to MPeti1, peterbecich, fxkr, jghaanstra and xet7.
The maximized card pane had no position of its own, so it remained an
in-flow item inside the scrolled board canvas and rendered off-screen
after scrolling down; desktop-mode floating-window rules also overrode
every maximize geometry rule, and inline drag offsets survived
maximizing. The pane is now viewport-fixed with insets that win over
both (drag position restores on minimize), RTL-safe. Regression test
with a CSS cascade resolver that fails on the pre-fix stylesheet:
tests/maximizedCardPosition.test.cjs.
Closes#3566: mobile shows one list at a time by design (xet7's own
comments in the issue); Move Card popup is the supported flow, and the
2021-era touch drag glitches were since fixed with drag handles.
Closes#3252: already fixed - comment deletes are guarded in
client/components/activities/comments.js (tagged #3252), checklists in
checklists.js, attachments via #5282.
Closes#3542: no code bug - redirect_uri is the same expression on the
client and server (mismatches come from ROOT_URL/proxy configuration,
per the Bug:Environment-specific label), and the login-style half was
fixed via #5695.
Thanks to pravdomil, 1ubuntuuser, gastoncollaud and xet7.
- CHANGELOG.md: Upcoming entries for the LDAP group filter fix (#4036),
invitation code regeneration (#4043), CJK add-card footer wrapping
(#4023) and team-to-board member sync (#4593), whose code shipped in
the previous commit.
- server/models/users.js: do not delete the invitation code in
onCreateUser before the account insert is committed - a failed insert
(duplicate username/email) burned the code for every retry (#4043).
Consumption happens after a successful insert; re-invites regenerate
stale codes.
- tests/teamBoardMemberSync.test.cjs: the #4593 regression tests (13,
positive and negative) for the team board-member sync helpers.
Thanks to zeisss-mercedes, jkoenig134, yuki-snow1823, Sylvain2703,
szymonsztuka and xet7.
#5695#4897#4654#5174#4825#5659#4730#4419#4158#4560#4036#1959#1971.
- Startup schema upgrade (server/lib/schemaUpgradeSteps.js): on start,
check that data from EVERY old WeKan version is migrated to the newest
structure and migrate only what is missing - all platforms, MongoDB and
FerretDB. Version-gated (marker stores WeKan version + datetime of the
last re-check; one findOne per boot until a new release), non-blocking,
live dashboard at /schema-upgrade-status showing the product name, fast
on big databases (distinct() set-joins, updateMany batches). Steps:
archived-flag backfill, swimlane structure + visibility rescue
(#1959#1971: cards under deleted/archived/foreign swimlanes reassigned
to a visible swimlane; card-insert hook validates supplied swimlaneIds),
merge-per-swimlane-lists (v7.98/v8.0x list copies merged back into
shared lists: no duplicate columns in Lists view, everything visible in
Swimlanes view, cards keep their swimlane), embedded checklist items,
customFields boardIds, allows* backfills, members isActive, permission
lowercase, filesystem path healing.
- Migration speed (5-hour reports): insertMany batches in the text phase,
preloaded target-record maps in the file phases.
- Snap attachment-repair + FILES_ONLY importer mode (see prior commit
wiring) extended with CFS FileSystem-store coverage
(ATTACHMENTS_STORE_PATH era), missing-binary reporting, and
migrate-gridfs-to-fs.mjs bucket fixes.
- OAuth2/OIDC: OAUTH2_LOGIN_STYLE=redirect honored (#5695); concurrent
logins no longer contaminate each other's user data (#4897); account
merge no longer wipes avatars/templates (#4560).
- LDAP: background sync fixed (#4654), password login rejected after LDAP
migration (#4419), LDAP_ENCRYPTION=true actually encrypts (#4158),
group filter accepts multiple groups and admits admin-sync groups
(#4036).
- All Boards tiles: per-list card counts + member avatars restored
non-reactively (#5174#4825). Uniform default list widths (#5659).
Declined invitations no longer resurrect membership (#4730).
- Tests with negative cases for every fix (tests/*.test.cjs; suite green
except the pre-existing environment-only htmljs failure).
Closes#5600: OAUTH2_CA_CERT already works - the fetch migration
(49a272d6c) applies the CA to all OIDC calls via https.Agent.
Closes#3828: board members seeing all board cards is by design (no
per-card visibility model), and organizations/teams now exist.
Thanks to mueschel, ArturRuta, gerardo-junior, fabianrbz, Miuler,
butteredCat-2021, Griiimm, preciousamorc, farwayer, LeoLu-eng, hnb1,
rangersdo and xet7.
- Migration importers: resolve the CollectionFS GridFS id from
copies.<bucket>.key too (the REAL old-WeKan layout; only
original.gridFsFileId / gridFsFileId / copies.gridfs.key were tried,
none of which exist there) via a shared resolveCfsGridFsId() in
releases/migrate-mongodb-to-ferretdb.mjs,
snap-src/bin/migrate-mongo3-to-ferretdb.mjs and
snap-src/bin/migrate-gridfs-to-fs.mjs. The modern importer now drives
CollectionFS extraction from cfs_gridfs.<bucket>.files itself, so a
missing/empty cfs.<bucket>.filerecord no longer silently skips every
file; binaries without a filerecord are still extracted to disk, and
filerecords whose binary cannot be located are reported on the
dashboard instead of dropped.
- Meteor-Files phase: match versions.*.meta.gridFsFileId without a
storage flag (WeKan's own getFileStrategy rule), handle every version
(not just 'original'), and add a bucket-driven sweep of <bucket>.files
by metadata.fileId so binaries are recovered even when the record's
flags say nothing about GridFS. GridFS-flagged versions with no
locatable binary are reported.
- mongo3 importer: copy the CollectionFS top-level boardId/cardId/
listId/swimlaneId/userId into meta on the created records - an
attachment without meta.cardId shows on no card.
- Admin Panel > Attachments: the Filesystem Storage paths were computed
from process.env.WRITABLE_PATH IN THE BROWSER, so they always showed
"/data". New admin-only getAttachmentStoragePaths method returns the
real Snap-aware paths (shared models/lib/attachmentStoragePath.js),
also used for the settings document default (was /data/attachments,
actual Docker path is /data/files/attachments).
- Snap: `snap run wekan.database ferretdb` now says it does NOT migrate
data, says when nothing was switched, and points at
`snap run wekan.migrate` for re-running the full migration.
- Tests with negative cases: tests/migrationAttachmentExtraction.test.cjs
(behavioral resolveCfsGridFsId from all three importers + wiring
guards) and tests/attachmentStoragePath.test.cjs, wired into
test:unit:node.
- Companion fix in wekan/FerretDB: accept documents with literal dotted
field names like MongoDB 3.6+, so migrated documents containing them
are no longer silently dropped.
- CHANGELOG.md: new Upcoming section with these changes.
If attachments are already missing after an earlier migration, run
`snap run wekan.migrate` - the source MongoDB data was never modified,
and the fixed importers re-create the attachment records and files.
Thanks to mueschel and xet7.
The right-docked card details window exposed two real issues in the
Playwright run (03-cards-operations failing in all three browsers):
- Archiving or deleting a card left its id in the openCards session
list, so the floating details window kept rendering above the board —
and, docked to the right edge, exactly over the archives sidebar,
intercepting its Restore/Delete clicks. Both handlers now drop the
card from openCards and clear currentCard.
- An OPEN board sidebar now stacks above the card window (z-index 2002
vs 2001), so the sidebar is always usable while a card is open.
Also from the same run: the new one-click cog spec closed its popup with
a keyboard Escape that proved unreliable across engines — it now uses
the popup's own X button (.js-close-pop-over) like 19-accessibility
does. The chromium-only 33-board-domains failure is an unrelated
token-login race in the auth helper (userId mismatch), not caused by
these changes.
tests/uiDensity.test.cjs got guards for both follow-ups (openCards
cleanup in archive+delete, sidebar z-index above the card window).
Updated ChangeLog.
Thanks to xet7.
tests/ferretdbHasData.test.cjs runs the real snap-src/bin/ferretdb-has-data
against crafted directories. This guard gates two critical switches
(migration-control's finish_success and mongodb-control's #6458/#6466
failure handler), so its semantics must never drift. Positive: non-empty
.sqlite, no -wal sidecar required (clean shutdown checkpoints it away),
one good file among empties. Negative: 0-byte .sqlite from a failed
migration, empty/missing directories, -wal/-shm-only leftovers, and a
DIRECTORY named *.sqlite. All eight behaviors verified against the
actual script. Wired into test:unit:node; ChangeLog updated.
Thanks to xet7.
The 2026-07-16_18-33-28 test run failed one spec in all three browsers:
the #6465 one-click board-settings cog added a second .js-open-board-menu
element, so 03-cards-operations' bare class locator resolved to 2
elements and tripped Playwright's strict mode. The archives test now
scopes the click to the sidebar's instance (.board-sidebar
.js-open-board-menu), keeping its 'from inside the sidebar' intent.
Also added a spec for the new cog itself to 15-board-actions: visible in
#header-main-bar, popup not open before the click (negative), ONE click
opens the real boardMenu popup (.js-open-archives inside), Escape closes
it again.
Thanks to xet7.
tests/cpuExecWiring.test.cjs, with negative cases: every Linux bundle in
release-all.yml embeds cpu-exec + its own arch's static qemu-user (arm64
and the QEMU-built extra arches replace the inherited amd64 one, extra
arches tolerantly), the Windows/macOS bundles strip both Linux-only
files, qemu-user-static is installed in every bundle-building job and
both sandstorm jobs, the Sandstorm .spk ships cpu-exec + qemu via
build-deps.sh (tolerant when qemu is not installed), the Docker
entrypoint and the bundle launcher route ferretdb/node through cpu-exec
while keeping direct-exec fallbacks for bundles that lack it, and the
snap ships cpu-exec via the snap-src helpers part. Wired into
test:unit:node; complements tests/cpuExec.test.cjs (the script's own
behavior).
ChangeLog Upcoming: the regression-tests entry now lists the cpu-exec
wiring test, the subtasks default-board test (#6456) and the FerretDB
fork's integration-test fixes.
Thanks to xet7.
Fixes#6456.
The lazily-creating getters for the default subtasks helper board and
its landing list still used the sync Boards.insert / Swimlanes.insert /
Lists.insert / Boards.update APIs that Meteor 3 removed from the server,
so creating a subtask crashed with 'insert is not available on the
server. Please use insertAsync() instead' whenever the ^Board^ helper
board had to be created. The list creator additionally read
getDefaultSwimline()._id, which is a Promise on the Meteor 3 server.
- getDefaultSubtasksBoardId / getDefaultSubtasksListId are now PURE
getters (no creation), matching the #3868/#2256 rule that only the
server may create these.
- The server-side lazy creation moved into getDefaultSubtasksBoardAsync
and getDefaultSubtasksListAsync using insertAsync/updateAsync and
getDefaultSwimlineAsync — the exact path addSubtaskCard uses.
- The never-called date-settings twins had the same sync calls and no
server-only guard at all; they are pure getters now too.
- tests/subtasksDefaultBoard.test.cjs guards the async creators and that
no sync collection writes come back to models/boards.js, wired into
test:unit:node.
- Updated ChangeLog.
Thanks to sjohnen and xet7.
That commit's message listed all ten issues after a single Fix keyword,
but GitHub only auto-closes a reference that directly follows its own
closing keyword, so only the first issue was closed on push. Closing
the rest here; the fixes themselves are already on main.
Fixes#6455. Fixes#6458. Fixes#6466. Fixes#6467. Fixes#6468.
Fixes#6472. Fixes#6465. Fixes#5547. Fixes#5282.
Thanks to xet7.
Fix#6458 completely: the reporter's host runs inside a hypervisor that
masks AVX, and the old per-tool AVX wrappers (amd64-only, PATH-based)
were bypassed by absolute-path mongod invocations.
- New general snap-src/bin/cpu-exec: runs any binary directly when the
CPU has the features it declares (--features x86_64=avx,aarch64=atomics
or WEKAN_REQUIRED_CPU_FEATURES) and through same-arch qemu-user when
not; plain zero-overhead exec with no declared features. Lookup order:
WEKAN_QEMU_USER, qemu-<arch> next to the script (bundle/Docker),
$SNAP/qemu-<arch>, the snap's migratemongo/avx one, then system
qemu-user(-static). Clear error + direct run when no qemu exists, so
the real SIGILL surfaces instead of hiding.
- Snap: mongodb-control and migration-control run every mongod 7 through
cpu-exec, so MongoDB works without AVX (slower) and migration can READ
modern MongoDB data on such CPUs; completed-FerretDB switch and
migration fallbacks unchanged (switch_to_completed_ferretdb extracted).
- release-all.yml: every Linux bundle .zip ships cpu-exec + this-arch's
static qemu-user (amd64/arm64/ppc64le/s390x/riscv64; stripped from
win64/mac bundles), flowing into Docker and Snap automatically;
Sandstorm .spk gets both via build-deps.sh. Bundle launcher and Docker
entrypoint route node/ferretdb through cpu-exec.
- Docs: mongodb-avx-qemu.md and mongodb-raspi4-qemu.md document the
built-in mechanism.
Tests, with negative cases, for the newest features and fixes at
changelog: htmljs array-vs-attributes (#6459), description draft
normalize/reset (#6455), comment draft lifecycle (#5547), attachment
delete guard (#5282), rules move actions + import normalization (#6472),
snap mongod-failure/migration recovery (#6458#6466), FerretDB polling
defaults (#6467#6468), UI density guards for every #6465 fix, and a
behavioral cpu-exec test against fake cpuinfo + fake qemu. All wired
into test:unit:node. Go table tests for the FerretDB SQLite filter
pushdown are in the wekan/FerretDB repo.
Updated ChangeLog.
Thanks to xet7.
- #6459: card More menu rendered empty (no Delete): the vendored jade
compiler's htmljs patch made isConstructedObject(Array) false, so
'label {{_ ...}}:' lines got their content array mis-assigned as tag
attributes and Blaze threw 'foreign objects in attributes' killing the
whole cardMorePopup. Also fixed the list More link input (nonexistent
rootUrl helper -> absoluteUrl).
- #6455: saving a card description never removed a pre-existing unsaved-
edits record, and the draft/description comparison mismatched on Markdown
hard-breaks and empty descriptions, re-creating a phantom draft on every
save. Save now clears the draft; both sides normalized the same way.
- #5547: comment drafts: the draft-saving escape handler had been disarmed
since 2019 (flag with no setter), so a comment being written was lost
when the card closed. Drafts are now saved continuously (debounced),
flushed on teardown, cleared on submit; text no longer visually vanishes
on outside clicks.
- #5282: attachment delete: guard against the doc being already evicted
from Minimongo ('Removed nonexistent document'), like the existing
comment/checklist guards.
- #6472: rules move card to top/bottom: fall back to the card's current
list when listName does not resolve (was a swallowed TypeError = rule
silently did nothing); wizard stored listTitle which the engine never
reads (listName); empty destination wrote sort +-Infinity; rules JSON/CSV
import now uses the rules.createRule method instead of client inserts
rejected into minimongo limbo, and defaults missing trigger matching
fields to '*'; empty boardId no longer overrides the real board; the
server-side orphaned-cards fallback in List.cards()/cardsUnfiltered()
now actually resolves its async swimlane lookup.
- #6465: desktop density back to WeKan 6.09: base font 14px and headings
22/18/16px (vw clamps resolved to 18/24px on desktop), All Boards
wrapper padding 10px/15px, card details docks to the right edge instead
of floating on top of its own card (still draggable), 20px canvas
padding instead of ~48px white borders, removed the force-all-card-text-
to-title-size rule, admin org/team table Select/Unselect-all header
links are compact icons and header cells may wrap, zoom pill no longer
cut off, one-click board settings cog in the board header.
- #6458#6466: snap: mongodb-control now checks mongod's exit status and
does an AVX pre-flight (MongoDB 5+ needs AVX; without it mongod SIGILLs)
instead of pinging a dead port forever behind a 502: it switches to a
completed FerretDB migration, or (re)runs the migration (AVX-free) with
a 3-attempt guard. Migration importers no longer fail the whole run on
>=10 per-item errors ('Avatars Errors' etc.), and a failed 3.x-source
migration keeps the copied FerretDB data + checkpoint and resumes next
start instead of deleting it and 'falling back' to a mongod 7 that
cannot open 3.x data files.
- #6467#6468: with FerretDB, calm Meteor's no-oplog polling storm
(METEOR_POLLING_THROTTLE_MS=2000, METEOR_POLLING_INTERVAL_MS=30000
defaults in the snap and bundle launcher; overridable). The FerretDB
fork gets filter pushdown, a sane pool size and less locking in its own
repo.
- Updated ChangeLog.
Thanks to xet7.
Follow-up to PRs #6469 and #6470:
- The login-time org/team sync now clears the inherited method invocation
context (DDP._CurrentMethodInvocation.withValue) around a normal
Meteor.callAsync, instead of invoking the raw method handler with a
hand-made invocation object. This goes through Meteor's normal method
dispatch (check() argument audits, EJSON argument cloning) while still
being the server-to-server path (connection null) that the admin guard
in setUserOrgsTeamsFromLdap allows.
- Added the ddp package dependency to wekan-ldap for the DDP symbol.
- Fixed indentation in localizeAvatarFromBuffer and restored the comment
explaining the proceedAfterUpload argument.
- Removed a stray double blank line in the LDAP login handler.
- Updated ChangeLog about the merged LDAP fixes.
Thanks to xet7.
Added a build-sandstorm job that runs after the GitHub Release is created,
with the same steps as the standalone sandstorm.yml workflow (which still
exists for testing the .spk build on its own), attaching
wekan-<version>-sandstorm.spk to the Release. Non-blocking, so the
experimental Sandstorm build never fails or delays the release.
Thanks to xet7.
Both snap jobs (snap-native and snap-launchpad) pushed only to candidate, beta
and edge, and stable had to be released by hand afterwards. Publish to
stable,candidate,beta,edge instead. base: core24 allows stable and candidate.
Thanks to xet7.
A big migration can run for 5 hours, so being interrupted by a snap refresh,
`snap stop` or a reboot is normal - but it was treated as a failure, and every
interruption threw away all of the work.
Distinguish interrupted from failed. snapd's SIGTERM killed the importer, bash
resumed at the line after the importer call, read the signal exit code (143) as
"the migration failed", and fail_and_run_mongodb deleted the partial FerretDB
SQLite and set migrate=off. Now a SIGTERM/SIGINT trap (and an importer exit code
>= 128, since snapd signals every process in the service cgroup) keeps the
partial database and the checkpoint, leaves auto-migration on, and hands back to
mongodb-control so WeKan keeps serving from MongoDB until the next start resumes.
Both importers flush their checkpoint on the signal and exit 128+signo.
Checkpoint files, not just collections. Only fully-copied collections were
checkpointed; the file phase started over. Worse, the destination path was picked
with an "append _1, _2, ... while the file exists" loop, so every already-
extracted attachment was written a second time under a new name, orphaning the
first copy - a resumed migration silently needed twice the disk the up-front
space check budgeted for. Files are now checkpointed individually (recorded only
once the bytes are on disk AND the record points at them, and re-verified by size
on resume, so a half-written file is never mistaken for a finished one) and
skipped when resuming. The path is now deterministic: idHex is the record's _id,
so two records never collide and an existing file there can only be this record's
own partial extraction, which is meant to be overwritten.
Discard the checkpoint together with the SQLite it describes. The checkpoint
lives in $SNAP_COMMON, not in the SQLite dir that discard_partial_ferretdb wipes,
so it survived. The next migration then trusted it, skipped every "already
migrated" collection, copied only the rest into the now-empty database, and
reported success - leaving the snap serving a FerretDB missing most of its data.
The MongoDB 3 importer had no checkpoint at all and now resumes collections and
files the same way. The source MongoDB data is never touched on any of these
paths.
Thanks to markusst1982 and xet7.
Meteor's accounts-base "resume" login handler projects a single array element
with the positional operator:
Meteor.users.findOneAsync(
{ 'services.resume.loginTokens.hashedToken': hashedToken },
{ fields: { 'services.resume.loginTokens.$': 1 } })
FerretDB rejects that find with "Executor error during find command :: caused
by :: positional operator '.$' couldn't find a matching element in the array"
(code 51246).
Resume is how every already-logged-in browser re-authenticates on page load and
on every DDP reconnect, so the throw logged users out, the client retried the
connection, and the retry loop pinned the FerretDB CPU - the board looked broken
right after a migration that had just taken hours.
Replace the handler with one that projects the whole loginTokens array and picks
the matching token in JS. Upstream already does exactly this in its own $or
fallback query ("Cannot use ...loginTokens.$ positional operator with $or
query"), so the array is known to be small enough to fetch, and behaviour is
otherwise unchanged - including looking up the hashed token on its own first so
the unhashed token is not sent to the database unless it has to be.
Closes#6457
Thanks to markusst1982 and xet7.
9.93 is released, so move the two commits made after it into a fresh
"# Upcoming WeKan ® release" section above v9.93, organized like the previous releases:
Features: database setting authoritative + snap run wekan.database mongodb|ferretdb +
no-downtime handling of a failed migration.
Bugs: migration skips dotted (GridFS/CollectionFS/system) collections that FerretDB
rejects, and cleans up a partial SQLite from a failed migration.
No entry text changed; only relocated.
Problem: the control scripts force-switched to FerretDB whenever a *.sqlite file existed, so
`snap set wekan database=mongodb` did not stick and a failed migration caused downtime with no
way to keep WeKan running on MongoDB while fixing it.
- The `database` snap setting is now AUTHORITATIVE. Removed the "FerretDB SQLite present ->
force ferretdb / disable mongodb" overrides from wekan-control, ferretdb-control and
mongodb-control. wekan-control keeps only the safety guard (never start an EMPTY FerretDB
while MongoDB has data).
- New `snap run wekan.database mongodb|ferretdb` command (bin/wekan-database): switch which
database WeKan runs on. `mongodb` also pauses auto-migration (migrate=off) so it does not
switch back; `ferretdb` requires a non-empty SQLite first.
- Auto-migration can be paused: migration-pending now also returns "not pending" when
`snap get migrate` == off. A migration that FAILS now runs fail_and_run_mongodb: delete the
partial SQLite, set migrate=off, and exec mongodb-control so WeKan keeps working on MongoDB
(no downtime, no retry loop). fall_back_to_mongodb likewise sets migrate=off instead of the
done marker. `snap run wekan.migrate` re-enables migrate and retries.
- finish_success now restarts wekan.wekan so it reconnects to FerretDB after a successful
migration instead of waiting for the now-stopped MongoDB.
Registered the `database` app in snapcraft.yaml and snapcraft-core26.yaml (also added the
previously-missing migrate/maintenance apps to core26).
Thanks to xet7.
Two bugs surfaced when the MongoDB 7 -> FerretDB migration finally connected (after the
db-eval fix):
1. FerretDB v1 rejects collection names containing a dot:
invalid key: "attachments.chunks" (key must not contain '.' sign)
Both importers tried to copy GridFS internals (attachments.chunks/.files, avatars.*,
cfs_gridfs.*) and CollectionFS cfs.<bucket>.filerecord collections as TEXT, aborting the
migration. Now the text phase skips ANY dotted collection: none of WeKan's real data
collections contain a dot, and the dotted ones are GridFS internals (extracted in the file
phase), CollectionFS filerecords (now turned into bare attachments/avatars records in the
file phase via replaceOne upsert:true) or system.* collections.
2. The failed migration had already copied some text collections, leaving a NON-EMPTY but
incomplete files/db/wekan.sqlite. ferretdb-has-data then saw it as "migrated", so
mongodb-control disabled MongoDB and the snap tried to serve a half-migrated FerretDB. On
any failure migration-control now runs discard_partial_ferretdb: stop the temp target
FerretDB and delete the partial SQLite, so the snap cleanly keeps MongoDB and retries. The
finish_success switch is also gated on it (`rc -eq 0 && finish_success`).
Source MongoDB data is never modified or deleted.
Thanks to xet7.
9.92 is released, so move everything committed after it into a fresh
"# Upcoming WeKan ® release" section above v9.92, organized by topic like the
previous releases (features, then bugs):
Features: wekan.migrate command; maintenance mode + maintenance page.
Bugs: db-eval driver resolution (ESM ignores NODE_PATH); decide FerretDB vs
MongoDB from a non-empty SQLite database (not the marker); mongod-7
readiness probe fast-fail.
v9.92 is restored to what it shipped, including its "migration-success marker is
now authoritative" bug entry (which the Upcoming "presence of a FerretDB SQLite
database" entry supersedes). No entry text changed; only relocated.
ready_via_node waits up to 45s for the temporary source mongod to accept connections, to
allow a large MongoDB 6/7 database time to replay its journal (#6454). Add a liveness check:
if the mongod process (SRC_PIDFILE) has already exited - e.g. mongod 7 cannot open old
MongoDB 3.x data - stop waiting immediately and drop to the MongoDB 3.2 reader, instead of
pinging a dead process for the full timeout. Matters across many unattended 6.09 -> 9.x
upgrades. (With --fork, start_mongod usually already returns non-zero when mongod cannot open
the data; this also covers a mongod that started then died mid-probe.)
Thanks to xet7.
For unattended upgrades at scale (6.09/MongoDB 3.2 -> 9.x/FerretDB across many servers), the
"did the migration succeed?" test must not be fooled by a 0-byte stub file.
- New shared helper snap-src/bin/ferretdb-has-data: exit 0 only if a *.sqlite file bigger than
0 bytes exists in files/db. Used by mongodb-control, ferretdb-control and wekan-control in
place of the previous "*.sqlite exists" glob, so the DB decision is based on a real,
non-empty FerretDB database. (Deliberately does NOT require the -wal file, which SQLite may
checkpoint away when FerretDB is stopped - that would cause false negatives at startup.)
- migration-control finish_success now verifies the non-empty SQLite database exists (and logs
the WAL/shm sidecars) BEFORE switching the snap to FerretDB. If the importer returns success
but wrote no data, it does not switch or set the done marker - MongoDB data is kept and the
migration retries on the next start.
Thanks to xet7.
db-eval is the Node helper the snap uses instead of mongosh to check whether MongoDB/FerretDB
is up, elect the replica-set primary, and probe mongod-7 readiness during migration. It did
`import { MongoClient } from 'mongodb'` while the wrapper set NODE_PATH to the bundled driver
-- but Node's ESM loader IGNORES NODE_PATH (only the CommonJS loader honors it). So the import
resolved nothing and db-eval exited BEFORE opening any connection, making every
ping/primary/rs-* check fail.
This single bug explains the whole family of failures seen this week:
- WeKan looping "MongoDB not ready yet, retrying..." / "FerretDB not ready yet..." forever
even though the database was running and listening;
- replica-set initialisation failing;
- the MongoDB -> FerretDB migration falling back to MongoDB 3.2 because the mongod-7
readiness probe never connected (mongod 7 opened the data fine, but db-eval couldn't reach
it), and 3.2 cannot read WiredTiger-7 files -> no FerretDB SQLite produced.
Proof from the migration source mongod log: mongod 7 reached "Waiting for connections" with
ZERO "Connection accepted" before the readiness timeout killed it; the only connection in the
file was the native `mongo` shell to mongod 3.2.
Fix: resolve the driver with createRequire (CommonJS resolution honors NODE_PATH and the
bundle layout), anchored inside the modern bundle (npm-mongo v6 first). Applied the same fix
to the standalone migrate-schema-v843.mjs and migrate-gridfs-to-fs.mjs tools.
Thanks to xet7.
wekan.migrate (bin/wekan-force-migrate): force a fresh MongoDB -> FerretDB migration,
ignoring the database setting and the migration marker. Removes any partial FerretDB SQLite +
resume checkpoint, sets database=mongodb, and starts wekan.mongodb so migration-control
re-reads the existing MongoDB (3 or 7) data and migrates again. Source MongoDB data untouched.
wekan.maintenance on|off (bin/wekan-maintenance): toggles a $SNAP_COMMON/.wekan-maintenance
marker. While present, mongodb-control / ferretdb-control do NOT auto-migrate or auto-disable,
so `snap start wekan.mongodb` or `snap start wekan.ferretdb` stays up and you can reach the
data over the MongoDB wire protocol on port 27019 (one at a time - they share the port).
Maintenance page (bin/wekan-maintenance-page.mjs): in maintenance mode wekan-control execs
this instead of WeKan; it serves an "under maintenance" page (HTTP 503) on the web port for
ALL URLs. It shows the Admin Panel product name if set (not "WeKan"), read from
$SNAP_COMMON/.productname.txt, which is cached while a database is running by wekan-control
(new db-eval `product-name` command) and by both migration importers - so it is available even
when both databases are stopped.
Registered `migrate` and `maintenance` apps in snapcraft.yaml.
Thanks to xet7.
Regression fix. An earlier change made mongodb-control/ferretdb-control/wekan-control key
the "use FerretDB / disable MongoDB" decision off the .migration-to-ferretdb-done marker.
But migration-control ALSO writes that marker when the migration falls back (data
unreadable, tools missing) or when there is nothing to migrate - producing NO FerretDB
data. So on a server whose MongoDB 7 -> FerretDB migration failed:
- mongodb-control saw the marker -> "migration already finished; disabling mongodb
service" -> disabled MongoDB;
- FerretDB SQLite (files/db) was EMPTY;
- database=mongodb, so wekan-control waited on MongoDB -> "MongoDB not ready yet,
retrying in 5 seconds..." forever, and wekan.mongodb refused to stay up.
Now all three scripts decide from ACTUAL DATA ON DISK: MongoDB is disabled / FerretDB is
forced ONLY when a *.sqlite database exists in files/db. An empty files/db means the
migration did not succeed, so mongod starts normally and WeKan keeps working (and the
migration can be retried). The marker still prevents re-running a finished migration.
Thanks to xet7.
Upcoming section: document that statfs is in snapd's default seccomp allow-list, so the
MongoDB -> FerretDB migration's free-space guard is active on Snap; quotactl is not used and
its absence is covered by the ENOSPC/EDQUOT write-failure fallback.
Document that statfs (and statfs64/fstatfs/fstatfs64/statvfs/fstatvfs) are in snapd's
default seccomp allow-list (snapcore/snapd interfaces/seccomp/template.go), so free-space
checks WORK inside a snap (which also has no per-snap disk quota by default, so statfs shows
real usable space). quotactl is NOT in the allow-list, but it is never called; a snapd
storage-quota group is still caught by the ENOSPC/EDQUOT write-failure path. Only Sandstorm
grains genuinely lack statfs (FUSE unimplemented, quotactl blocked). No behaviour change.
migrate-mongodb-to-ferretdb.mjs (the modern MongoDB 6/7 driver importer that
migration-control runs, packaged from releases/):
- Resolve the mongodb driver by probing the WeKan bundle with createRequire anchors and
USE WHAT WORKS: prefer a v6+ driver that exposes GridFSBucket and speaks OP_MSG, since
an older bundled v2 driver's OP_QUERY is rejected by FerretDB ("Unsupported OP_QUERY
command: update"). A plain `import from 'mongodb'` could pick up that v2 driver. Fail
fast with a clear message if no usable driver is found.
- Bring it to parity with migrate-mongo3-to-ferretdb.mjs's data-safety and UX: measure
total attachment/avatar bytes up front and STOP before extracting if they will not fit;
if space runs out mid-run, stop + delete the partially migrated files + report how much
more disk is needed (a full disk can corrupt the still-running source MongoDB);
detect ENOSPC/EDQUOT where free space is not measurable (Sandstorm); show a live
per-file progress bar; and translate the dashboard into the browser's language.
Existing checkpoint/resume, schema upgrade, orphan fixing, compaction and index
creation are unchanged.
wekan-control:
- On startup, decide the database from what data actually exists on disk (FerretDB SQLite
at $SNAP_COMMON/files/db, MongoDB WiredTiger at $SNAP_COMMON), not the `database` setting
alone. If ferretdb is selected but its SQLite is empty while MongoDB still has data,
revert to database=mongodb instead of starting an EMPTY FerretDB that would look like all
data was lost, and tell the user to run the migration first.
Thanks to xet7.
Symptom: WeKan never started, looping "MongoDB not ready yet, retrying in 5 seconds..."
forever, even though mongod appeared to be running.
Cause: mongodb-control started mongod with a HARDCODED --wiredTigerCacheSizeGB 32. On any
server with less than ~34 GB RAM, mongod was OOM-killed seconds after startup. That
included the temporary mongod started to initialise the replica set: it died before
db-eval could reach it (log showed "child process started successfully" then 30 s of
failed pings), so the replica set was never initiated. The final mongod then ran with
--replSet rs0 but no config, no PRIMARY was elected, and wekan-control (which needs the
replica-set primary for Meteor change streams) waited forever.
Fixes in mongodb-control:
- WiredTiger cache is now RAM-aware: ~50% of (MemTotal - 1 GB), the same formula mongod
uses for its own default, capped at 32 GB, min 1 GB. Override with
MONGODB_WIREDTIGER_CACHE_GB. Applied to both the temp replica-set-check mongod and the
final mongod.
- Temporary-mongod readiness wait raised 30 s -> 90 s so a large database that needs
longer to replay its journal still gets its replica set initialised/reconfigured.
Fix in migration-control:
- The temporary source mongod started to READ the data during a MongoDB -> FerretDB
migration now uses a conservative RAM-aware cache (1/4 of (MemTotal - 1 GB), cap 8 GB,
override MIGRATION_MONGOD_CACHE_GB), leaving room for the target FerretDB and the Node
importer that run alongside it. Applied only to the mongod 7 (WiredTiger-only) read so
the flag can never clash with a legacy MMAPv1 MongoDB 3.x dbpath.
Thanks to xet7.
Symptom: on an already-migrated install, `sudo snap start --enable wekan.ferretdb`
started FerretDB and then it immediately stopped itself, logging:
"database is 'mongodb', not 'ferretdb'. Disabling ferretdb service."
Cause: every DB service keyed its behaviour off the `database` snap setting alone. If
that setting was never flipped to ferretdb (e.g. the migration's INTERNAL `snapctl set`
did not re-run the configure hook), ferretdb-control read `database=mongodb` and disabled
itself, so FerretDB could not be started by hand without first running
`snap set wekan database=ferretdb`.
Fix: the marker $SNAP_COMMON/.migration-to-ferretdb-done is now authoritative.
- ferretdb-control: if the marker exists, repair database=ferretdb and keep running
instead of self-disabling.
- mongodb-control: if the marker exists, repair database=ferretdb and disable mongodb,
BEFORE the migration-pending check so a finished migration is never re-attempted.
- wekan-control: already forces ferretdb on the marker (previous commit).
Immediate recovery on an already-migrated install running an older release:
sudo snap set wekan database=ferretdb
Thanks to xet7.
wekan-control (the wekan.wekan service) only WAITED for the database DATABASE points at
and never started a DB service, so if both wekan.ferretdb and wekan.mongodb were
stopped/disabled WeKan hung on "MongoDB not ready yet, retrying..." forever.
Now, on start, wekan-control:
1. If the migration-success marker $SNAP_COMMON/.migration-to-ferretdb-done exists,
forces database=ferretdb, then enables + starts wekan.ferretdb and stops + disables
wekan.mongodb. This self-heals the case where the migration's INTERNAL `snapctl set`
never re-ran the configure hook that flips the services.
2. Before waiting, enables + starts whichever DB service is configured
(snapctl start --enable = snap enable + snap start), so a merely-stopped DB is
brought back up instead of WeKan waiting forever.
Uses the snap instance name so parallel installs target their own services.
Thanks to xet7.
v9.91 was cut as a release, so move the Snap FerretDB service-flip fix out of it into a
fresh "# Upcoming WeKan ® release" section above v9.91. No entry text changed; only
relocated.
After a MongoDB -> FerretDB migration, WeKan hung on "MongoDB not ready yet, retrying..."
because no database was running: wekan.ferretdb stayed disabled and wekan.mongodb stayed
enabled-but-stopped.
Root cause: the wekan.ferretdb service disables itself while database=mongodb, and the
service flip that re-enables it lives in snap/hooks/configure. migration-control switches
the backend with an INTERNAL `snapctl set database=ferretdb`, but an internal snapctl set
does not re-run the configure hook, so the flip never happened.
Fix: finish_success now does the flip itself (mirroring the configure hook's ferretdb
branch): enable+start+restart wekan.ferretdb, then stop+disable wekan.mongodb, using the
snap instance name so parallel installs target their own services. FerretDB is started
before MongoDB is disabled so a DB is up first.
Immediate recovery on an already-migrated install:
sudo snap start --enable wekan.ferretdb && sudo snap stop --disable wekan.mongodb
v9.90 (2026-07-15) was already cut, but later work had been appended to it. Create a new
"# Upcoming WeKan ® release" section above v9.90 and move into it everything committed
after the v9.90 cut:
- new features: Snap/Sandstorm migration dashboard (per-file progress + disk guard)
- updates: i18n 10 more languages, native-name fixes, pull English-regression report
- tests: dev server also frees the MongoDB port
- bugs: MongoDB 3->FerretDB EJSON + stay-on-page; "Always show all code as plain text"
reactivity race; i18n browser-language -> file mapping fixes
v9.90 is restored to its cut contents (MimeBleed CRITICAL + the original features/updates/
tests/bugs). No entry text changed; only relocated.
Document the Upcoming i18n work: the ja_JP->ja clobber fix, case/underscore-insensitive
language matching, Chinese subtag fallback + zh alias, the cmn tag typo fix (bugs), and
the 10 new selectable languages, native-name corrections, and the pull-translations
English-regression report (updates).
Add languages.js entries for translation files that had none (so they were pulled from
Transifex but never selectable): ca-valencia (Català (Valencià)), en_ID/en_SG/en_TR
(English (Indonesia/Singapore/Turkey)), es_CO (Español (Colombia)), fr-FR (Français
(France)), pt_PT (Português (Portugal)), ru-UA (Русский (Украина)), tk_TM (Türkmençe
(Türkmenistan)), wuu-Hans (吴语（简体）). Skipped km_KH and ru_RU (duplicate the existing
km-KH / ru-RU entries) and zh (already aliased to zh-Hans).
Fix language names that used the English name instead of the native one:
ace "Acehnese" -> "Bahsa Acèh"
cy "Welsh" -> "Cymraeg"
cy-GB"Welsh (UK)" -> "Cymraeg (Y Deyrnas Unedig)"
af_ZA"Afrikaans (South Africa)" -> "Afrikaans (Suid-Afrika)"
Fix several browser-language -> translation-file mapping gaps:
- isLanguageSupported is now case-insensitive (requested) via a new TAPi18n.resolveTag()
that maps any input to the canonical languages.js tag case-insensitively AND
underscore<->hyphen-insensitively (so 'zh-hant'->'zh-Hant', 'JA-JP'->'ja-JP', browser
'af-ZA'->legacy key 'af_ZA'). loadLanguage/setLanguage/ensureLanguageLoaded resolve
through it, so the loaded file, the i18next code and the stored current tag all agree.
- Bare base codes with no plain-code file resolve via an alias map: 'zh' -> 'zh-Hans'
(Chinese has only script/region files), so plain 'zh' gives Simplified, not English.
- Browser detection (client/lib/i18n.js) now strips trailing subtags progressively
instead of jumping to the first segment: 'zh-Hans-CN' -> 'zh-Hans', 'zh-Hant-TW' ->
'zh-Hant' (Chrome sends these), rather than -> 'zh' -> English.
- languages.js: fix the 'cmn' entry whose tag was the typo 'cnm' (and code 'cn'), which
mismatched supportedLngs and broke selecting Mandarin; now tag/code = 'cmn'.
Adds i18n.test.js coverage for resolveTag, case-insensitive isLanguageSupported, the zh
alias, the underscore/hyphen match, and each Japanese variant loading its own file.
Two Transifex languages were writing to the same local file: .tx/config lang_map had
`ja_JP: ja`, which sent Transifex's ja_JP INTO imports/i18n/data/ja.i18n.json — the same
file the real Japanese (`ja`) uses. On `tx pull -a -f`, the emptier/untranslated ja_JP
overwrote ja.i18n.json, reverting Japanese strings to the English source. Map it to its
own file instead: `ja_JP: ja-JP` (-> ja-JP.i18n.json), matching languages.js which already
has three separate Japanese entries (ja -> ja.i18n.json, ja-JP -> ja-JP.i18n.json,
ja-Hira -> ja-HI.i18n.json). No other lang_map target collides. languages.js already loads
each to its own file, so no change needed there.
Also add releases/translations/report-english-regressions.mjs and call it from
pull-translations.sh: after pulling, it lists the language files where a previously
translated string reverted to exactly the English source (i.e. untranslated on Transifex),
so the regression is visible instead of being committed silently.
The MongoDB 3 -> FerretDB migration work had grown into one large bug bullet that
actually contained major features (live per-file progress bar, chunk-by-chunk streaming,
disk-space safety guard + rollback, Snap/Sandstorm/availability detection). Move those to
the "new features" section as their own bullet, and keep the EJSON-resolution fix +
stay-on-page hand-off as the bug entry (with a pointer to the feature bullet).
Previously the statfs free-space guards were gated on IS_SNAP. But a Snap container may
also be unable to report free space (statfs fails). Drive the behaviour off whether free
space is actually MEASURABLE instead:
- updateDiskFree: skip statfs only on Sandstorm (where it is known-unreliable — reports the
host disk, not the grain quota); everywhere else ATTEMPT statfs, and on failure leave
state.diskFree < 0 (unknown).
- ensureDiskForFile / the up-front total-size pre-check: run only when state.diskFree >= 0
(measurable); otherwise skip and rely on an ENOSPC/EDQUOT write failure.
- Dashboard already hides the free-space figure and switches to "free space required for
all files" whenever diskFree < 0, so a Snap-with-no-statfs degrades exactly like
Sandstorm: try, and stop + delete + report on a write failure.
IS_SNAP is now only used for the platform log line. CHANGELOG updated.
The statfs free-space checks only make sense on the Snap (a real filesystem whose size we
can read). A Sandstorm grain cannot see its free space or quota — its FUSE layer does not
implement statfs and quotactl is blocked (confirmed in the Sandstorm source), and statfs
on the writable /var reports the host disk, not the grain quota. So:
- Detect Snap via $SNAP (IS_SNAP) and Sandstorm via SANDSTORM / SANDSTORM_RAW_MONGO_PATH /
METEOR_SETTINGS.public.sandstorm (IS_SANDSTORM).
- Run the statfs up-front + mid-run free-space guards ONLY on Snap.
- On Sandstorm (and anything else), just try to migrate and detect "out of space" from an
actual ENOSPC/EDQUOT write failure (in the streaming writer and in the file-loop catches),
which triggers the same stop + delete-migrated-files + report rollback (onDiskAbort).
- Dashboard shows the free-space figure only when known (Snap); on Sandstorm it says free
space is unknown and phrases the requirement as "free space required for all files".
Sandstorm source used only for research (grain cannot query disk/quota); not committed.
CHANGELOG updated.
Add the missing Upcoming bug entry for the alwaysShowCodeAsText fix (the viewer read a
stale ReactiveVar and never re-rendered, so the toggle did nothing; now set inside the
mentions helper from the same reactive setting it already reads). The MongoDB 3 ->
FerretDB migration progress/disk-guard improvements were already recorded in the mongo3
migration entry.
Migration dashboard + migrator improvements for the MongoDB 3 -> FerretDB path:
- Live per-file progress: the file currently being extracted shows its name, size,
"file N of TOTAL", a percent progress bar, and whether it is an attachment or an
avatar. File-type words use WeKan's existing translations in the viewer's browser
language (Accept-Language), read best-effort from the bundle with an English fallback.
- RAM-safe streaming: each GridFS file is streamed chunk-by-chunk (sorted by n) straight
to disk via a spawned mongoexport + readline, with natural back-pressure, so a multi-GB
attachment never lands in memory. The old approach buffered the whole file through
mongoexport's 512 MB stdout maxBuffer and failed on big files.
- Disk-space guard (a full disk can corrupt the still-running source MongoDB): the
dashboard shows remaining free space; the migrator measures the total size of all
attachments+avatars up front and stops immediately if the volume cannot hold them; it
also stops mid-run if free space drops below a safety margin (default 1 GB,
MIGRATION_MIN_FREE_BYTES). On such a stop it deletes the partially-migrated files to
free the space back, reports how many files were migrated before stopping, and shows how
much more disk space is required to migrate all files.
Cannot run the snap here, so this is reviewed but not executed; needs a snap migration run
to verify. CHANGELOG updated.
The MongoDB 3 migrator resolves WeKan's modern bson (with EJSON) and mongodb v6 by
anchoring require() inside the Meteor bundle. It anchored the sub-paths relative to the
script, but in the snap the script runs from $SNAP/bin/ while the bundle is at
$SNAP/programs/server/... (one level up) — so every anchor resolved
$SNAP/bin/programs/server/... (nonexistent) and fell through to the ancient meteor-spk
base bson 1.x with no EJSON, giving "FATAL: EJSON.parse unavailable" and aborting the
migration.
Build candidate bundle roots from $SNAP (env) and the script's parent dirs, then try the
known modern-bundle sub-paths under each (npm-mongo's nested v6 driver first, so the
ancient v2 that FerretDB rejects with OP_QUERY is never chosen). Node's module resolution
walks up from the '_.cjs' anchor to programs/server/npm/node_modules/bson.
Also: on successful hand-off the dashboard now reloads the SAME page the user was on
(the board URL) instead of forcing All Boards, so a reload during migration keeps you in
place. The dashboard already serves the progress page for every URL. CHANGELOG updated.
The viewer (mentions -> markdown) applies alwaysShowCodeAsText via a ReactiveVar
(Markdown.alwaysShowCodeAsText) that only a separate startup Tracker.autorun kept in
sync with the setting. But the mentions helper re-renders whenever the settings doc
changes (it reads getCurrentSetting for renderLinksAsPlainText/stripLinks), and that
re-render often runs BEFORE the bridge autorun updated the ReactiveVar — so the inner
markdown helper read the stale flag and rendered links/markdown normally (clickable),
and since mentions does not depend on that ReactiveVar it never re-rendered again.
Net effect: toggling "Always show all code as plain text" did nothing (links stayed
clickable, code stayed rendered), even after reload (same race on load).
Fix: set Markdown.alwaysShowCodeAsText inside the mentions helper, from the same
reactive getCurrentSetting() it already reads, BEFORE rendering the inner markdown
via Blaze.toHTML. The markdown helper now always reads the up-to-date flag in the same
synchronous render, so the toggle takes effect immediately in every rich-text field
(card titles, descriptions, comments, checklists). The startup autorun stays for any
direct +markdown use outside a viewer.
kill_meteor_on_port freed the app port (3000) and rspack dev-server port (8080) but not
Meteor's bundled MongoDB on app-port+1 (3001). When the meteor parent is SIGKILLed its
mongo child is often orphaned and keeps holding 3001, so the next `meteor run` failed
with "Unexpected mongo exit code 48 ... port was closed, or was already taken". Also
free app-port+1 (which additionally clears a leftover standalone test mongod on :3001),
include it in the readiness guard/wait, and in the SIGKILL escalation. CHANGELOG noted.
Bring the Windows batch runner to parity with rebuild-wekan.sh: the :3000 server for
Node E2E + Playwright now runs from the precompiled .build\bundle instead of
`meteor run`, so no recompile. New :start_bundle_server subroutine (used by both the
parallel and sequential "Run ALL tests" flows):
- Builds .build\bundle once if missing (meteor build .build --directory).
- Resolves Meteor's bundled node via `meteor node -e process.execPath` and the sibling
dev_bundle mongod; runs the bundle with that node (native-module ABI match).
- Installs the bundle's programs\server npm deps once.
- Starts Meteor's mongod on :3001 (db "meteor", matching what the tests seed), or reuses
a MongoDB already listening there; stops it on exit only if this run started it.
- Starts `node .build\bundle\main.js` with MONGO_URL/ROOT_URL/PORT/WRITABLE_PATH set in
the parent scope (child inherits them) then unset so Mocha/E2E do not inherit MONGO_URL.
Mocha still uses `meteor test` (:3100, its own build) — it cannot run from a production
bundle. Intro text and cleanup updated; CHANGELOG notes the parity. Untested on Windows
here (no cmd available); needs one Windows verification run.
Group the Upcoming section under the standard headers: CRITICAL SECURITY ISSUE
(MimeBleed), new features (import/export privacy, always-show-code, render-links),
updates (webhook card description, Sandstorm docs), tests (yargs mocha crash, live
progress, .build/bundle reuse), bugs (Sandstorm migrated-grain Admin Panel, Version
storage engine). Also fold the bundle-server "meteor" vs "wekan" database fix into
the .build/bundle test entry.
The bundle-based :3000 server pointed at mongodb://127.0.0.1:3001/wekan, but the
Playwright and Node E2E tests seed their users/boards straight into
mongodb://127.0.0.1:3001/meteor (tests/playwright/helpers/db.js,
tests/e2e/list-regressions.js) — the DB name Meteor's built-in mongo used under the
old `meteor run`. Same mongod, different database: the app read an empty DB while the
tests seeded another, so every test needing seeded data failed (only the ~9 per browser
that need no seed passed). Point the bundle server at /meteor so app and tests share
one database again.
Complete the Upcoming test-infrastructure notes: the readiness poll that hung on
Meteor's :3000 proxy (progress froze at [0s]) is now fixed with a curl timeout and a
wall-clock-bounded wait, and "Run ALL tests" checks for .build/bundle specifically and
builds it once if missing. Also note the .sh (bundle) vs .bat (meteor run) split in the
server-start wait item.
Before running ALL tests, check for the .build/bundle directory specifically (the
:3000 test server runs it). If it is missing (never built, or a previous build left
.build without a bundle), build it with `meteor build .build --directory` first.
Previously it only checked the .build parent, so a missing/partial bundle was not
rebuilt here (only caught later by the main.js check).
"Run ALL tests" started the :3000 server with `meteor run`, which recompiles into
.meteor/local even after you already built .build/bundle. Node E2E + Playwright only
need a live WeKan over HTTP, so start that server from the precompiled bundle instead:
- `node .build/bundle/main.js` with Meteor's bundled node (matching native-module ABI),
MONGO_URL to Meteor's bundled mongod on :3001 (or reuse a MongoDB already listening
there). Boots in seconds, no recompile. One-time `programs/server` npm install runs
if missing. mongod is stopped on exit only if this run started it.
- The server boot log and the npm install now STREAM LIVE (scrolling: tail -n 0 -f /
tee) so you see exactly what is happening instead of a single frozen summary line.
- Sequential mode runs suites strictly one at a time, each streaming its own output;
the parallel-only combined refreshing table is now skipped in sequential mode.
Mocha still uses `meteor test` (its own .meteor/local-test build) — its in-process
server-side tests cannot run from a production bundle, so that one build is unavoidable
and copying the bundle would not help it. The script warns the bundle is run as-is, so
rebuild it after source changes. CHANGELOG updated.
In sequential mode only one suite runs at a time, so there is no reason to hide its
output in a log and show only a counter. Refactor the job runner: extract run_job_body
(the actual suite command) and, in sequential mode, pipe it through tee straight to the
console — you now see every test tick by one-by-one as the reporter prints it, then a
final PASS/FAIL + count line. Parallel mode still runs jobs in the background to logs
(the combined table reads them). tee is on the right of the pipe so the suite's exit
code is captured in STATDIR, not tee's.
The "Building WeKan" message during Run ALL tests suggested a fresh full build even
though the user had already built WeKan. Reword it: the tests start a live
`meteor run --port 3000`, and Meteor recompiles into .meteor/local on start only for
inputs that changed since the last build (sources / node_modules), then caches it.
No behavior change, message only.
The "Run ALL tests" server-readiness wait used `curl http://127.0.0.1:3000/sign-in`
with no timeout. Meteor binds the :3000 proxy early and accepts the TCP connection
while the app is still building, but does not send an HTTP response until the build
finishes. So curl blocked on that first connection for the whole build: the loop
never advanced and the new progress line froze at [0s] with only the log header,
even though the build was progressing in the log.
Give curl --connect-timeout 2 --max-time 4 so each poll returns quickly (not-ready
during the build, ready once /sign-in actually answers). The elapsed seconds and the
newest build step now refresh every few seconds as intended. Bound the wait by
wall-clock time (.sh: 1200s; .bat: ~240 polls) instead of a fixed count, since polls
now take a few seconds each. Also add the timeout to the Playwright-ALL precheck.
Audited both runner scripts and closed every place that used to sit silent for
minutes during test runs:
- Server first-build wait (Run ALL tests, both modes): .sh shows elapsed seconds +
newest build step from the server log in place; .bat shows elapsed seconds every
~10s and points at the live build log (echoing arbitrary build lines is unsafe on
cmd because they contain > < | &).
- Sequential per-job (option 2): .sh prints a live elapsed + pass/fail counter per
job and a final PASS/FAIL line; .bat now runs each job in its own minimized window
(reusing the proven parallel start-commands + .done-<key> flags) and polls a live
pass counter one job at a time, instead of redirecting silently to a log.
- Playwright ALL browsers single menu item (.sh option 10 / run_playwright_parallel):
streams each browser's list reporter live via tee while still saving the log;
PIPESTATUS[0] keeps per-browser pass/fail accurate through the pipe.
Single-suite items (Mocha, import, E2E, single Playwright) and the parallel combined
progress table already showed progress and are unchanged. CHANGELOG updated.
Record the Upcoming test-infrastructure change: "Run ALL tests" now shows elapsed
time + newest build step during the server build, and a live per-job pass/fail
counter in sequential mode, instead of sitting silent for minutes.
Running ALL tests (menu options 1/2) was silent for minutes in two places:
- While the :3000 WeKan server did its first rspack build, the readiness wait only
printed dots. Replace that with an in-place line showing elapsed seconds and the
newest build step from the server log (=> Compiled Rspack..., => Started MongoDB,
=> Started your app), so the build is visibly progressing.
- In sequential mode each job blocks until it finishes, so nothing showed while a
job built and ran. Add a live in-place counter per job (elapsed seconds + tests
passed/failed, from count_pass/count_fail on the job log) and a final PASS/FAIL
line when it completes.
The parallel-mode combined progress table is unchanged.
Update the "Test infrastructure" Upcoming entry with the confirmed root cause and
resolution: the second-stage boot crash was node_modules/yargs-parser/build/lib/index.js
using the guarded ternary `const require = createRequire ? … : undefined`, fixed by
generalizing the createRequire removal to a line-wise match (run before import.meta.url
expansion) and broadening the scan from node_modules/yargs to yargs and its ESM deps.
Also note the three server test files that were present but missing from the curated
server/lib/tests/index.js loader and are now registered. Verified: 450 passing, 0 failing
(411 before the three files were wired in).
The Mocha (server-side) test bundle crashed at boot with 0 tests run because
yargs and its ESM dependencies are dragged into the Meteor test server bundle,
where Meteor 3 wraps every module in a CommonJS function and their native-ESM
constructs (import.meta, `const __dirname`, `const require = createRequire(...)`)
are illegal and crash the bundle before any test runs.
Two gaps remained in scripts/patch-yargs-dirname.cjs:
- The `const require = createRequire(...)` removal (and its trigger) only matched
the direct-call form. yargs-parser/build/lib/index.js uses the guarded ternary
`const require = createRequire ? createRequire(import.meta.url) : undefined;`,
which slipped through and crashed at boot with "Identifier 'require' has already
been declared". Generalized the match to line-wise `const require = ...createRequire...;`.
- The scan only walked node_modules/yargs, so yargs-parser (the actual offender)
was never patched. Broadened the scan to yargs and its ESM dependency packages.
Also register the three server test files that were present but missing from the
curated server/lib/tests/index.js (they never ran): the MimeBleed file-validation
bypass regression, the import/export privacy settings, and the impersonation report
query. Server suite now boots and runs (411 passing).
CHANGELOG Upcoming documents the bug and the two-stage debugging journey.
The yargs postinstall patch expanded import.meta.url -> require('url').pathToFileURL(...)
BEFORE removing the const require = createRequire(...) call. The paren-naive removal
regex createRequire([^)]*) then stopped at the first ) of the injected require('url'),
replacing only part of the statement and leaving a dangling
/* Meteor: use wrapper require */.pathToFileURL(__filename).href));
in yargs' esm.mjs. That is invalid JS (a leading .pathToFileURL after a comment), so
Meteor's reify parser threw 'Unexpected token (19:33)' when the test server bundle pulled
yargs in -- meteor test reported 0 tests, even though every repo source file was fine.
Fix: remove the createRequire call BEFORE expanding import.meta.url (so the injected
parens can't break the match), and add a repair rule + trigger so re-running the script
collapses the dangling leftover in already-corrupted node_modules/yargs files back to the
marker. Fresh and already-broken files both end valid.
- models/fileValidation.js: a stray BOM (U+FEFF) inside the looksLikeDangerousMarkup
regex character class broke the server test build with a Babel 'Unexpected token'
syntax error, so Mocha ran 0 tests. JS \s already matches U+FEFF, so the explicit
BOM was redundant; use plain \s*.
- models/import.js: importBoard awaited assertImportEnabled() BEFORE the switch that
check()s the "board" argument. Meteor's audit-argument-checks tracks checks on the
async context, so awaiting first made the later check(board) not count, throwing
'Did not check() all arguments during call to importBoard' -- which broke the WeKan
JSON import (#21) and Excel import (#25) Playwright tests. Check "board" up front
(Match.OneOf(Object, Array)) before the await; the per-source switch still does its
specific check.
- server/publications/activities.js: move the disableActivities gate to AFTER the
check() calls so the argument-checks audit is satisfied when the toggle is on
(latent: it would have thrown 'did not check all arguments' with activities off).
Supersede the earlier 'keep MongoDB 7' approach: the WeKan snap now moves EVERY
existing MongoDB database onto FerretDB (SQLite) on first boot after an upgrade,
then shuts MongoDB down so only WeKan (Node.js) + FerretDB (SQLite) run. Text data
goes into SQLite; CollectionFS + Meteor-Files GridFS attachments/avatars are
extracted to files/attachments and files/avatars.
migration-control now routes by how the source can be READ, not by keep-vs-migrate:
- mongod 7 can open it (modern MongoDB 6/7, incl. a DB earlier migrated up from 3.x)
-> keep that mongod as source, run the modern driver importer
(migrate-mongodb-to-ferretdb.mjs) into a temp FerretDB SQLite target.
- else mongod 3.2 can open it (old MongoDB 3.x) -> run migrate-mongo3-to-ferretdb.mjs
(legacy mongoexport CLI).
- else (unreadable/corrupt, or tools missing) -> fall back to a normal MongoDB start
so the service is never left dead, and retry next boot.
On success: mark done + snapctl set database=ferretdb; mongodb-control then stops and
disables the MongoDB service. This also fixes the reported failure where a healthy
MongoDB 7 database was misdetected as MongoDB 3.x, the 3.x path failed, and — because
mongodb-control exec's this script — mongod never started and the service looped.
Probe readiness lengthened 20s -> 45s; the temp source mongod is tracked by pidfile
and force-stopped so it never leaves the dbpath locked. MongoDB data is never
modified or deleted; the snap only switches to FerretDB once migration succeeds.
Both migration dashboards (Snap MongoDB-3 importer and the Sandstorm/general
MongoDB importer) hard-coded 'WeKan'. If the migrated database has a product name
set in Admin Panel (settings.productName), the dashboard now shows that name and
does not mention WeKan; otherwise it defaults to WeKan.
- snap-src/bin/migrate-mongo3-to-ferretdb.mjs: read settings.productName via
mongoexport early in run() into state.product; title/h1/complete message use it.
The importer->app hand-off poll no longer keys off the product-dependent title
string; it checks a stable '<!--migration-dashboard-->' marker instead.
- releases/migrate-mongodb-to-ferretdb.mjs: read settings.productName via the driver
right after the source connects into state.product; the HTML __PRODUCT__ placeholder
is substituted in buildHtml(). Header clarified to FerretDB (SQLite).
The one-time MongoDB 3 -> FerretDB migration check probed whether mongod 7 could
open the existing data and, if that short probe failed for ANY reason (journal
recovery, stale mongod.lock, slow disk, large oplog), assumed the data was
MongoDB 3.x. A healthy MongoDB 7 database that failed the probe was then sent down
the 3.x path, where mongod 3.2 also could not open it, logging 'could not start
migratemongo mongod on the MongoDB 3.x data'. Because mongodb-control exec's the
migration script, mongod never started -- the MongoDB service failed to activate
and looped on every restart.
Fix: only run the 3.x migration when the data is POSITIVELY confirmed as MongoDB
3.x (mongod 3.2 can actually open it). In every other case -- MongoDB 6/7, data the
probe could not read, or missing tools -- fall back to a normal MongoDB 7 start in
the same service activation (set the marker + exec mongodb-control) instead of
exiting with nothing running. Also: lengthen the mongod-7 readiness probe 20s -> 45s
so large databases needing recovery are not misread, and track the temporary probe
mongod by pidfile + force-stop it so it never leaves the dbpath WiredTiger lock held.
The MongoDB data is never modified or deleted.
- client/lib/tests/renderLinksPlainText.tests.js: the 'render links as plain text'
toggle and XSS hardening. Config assertions (stripLinks adds <a> to FORBID_TAGS,
default does not, KEEP_CONTENT) plus real sanitizeHTML() behavior: <a> stripped to
its text when stripLinks, kept by default, and javascript: hrefs / event handlers /
<script> removed regardless.
- client/lib/tests/alwaysShowCodeAsText.tests.js: escapeHtmlSource (exposed on the
Markdown export) escapes <script>/comments/quotes/ampersand-first so code is shown
not executed; leaves plain text and empty strings unchanged.
- server/lib/tests/impersonationReportQuery.tests.js: the Impersonation report search
selector (extracted to models/lib/impersonationReportQuery.js so it is testable
without re-registering the publication) builds a case-insensitive $or across the
identity fields, escapes regex metacharacters, and is empty for a blank term.
The MimeBleed fix (fileValidationBypass.security.tests.js), SortBleed
(boards.security.tests.js) and import/export anonymization
(importExportSecurity.tests.js) already carry positive + negative tests.
WeKan's upload validation (models/fileValidation.js) detects a file's real MIME
type by running the Unix 'file' command. On minimal Docker/Alpine images without
'file', detectMimeFromFile() silently returned undefined and the code fell back to
the CLIENT-supplied fileObj.type. An authenticated board member (WITH_API=true)
could upload HTML+JS while setting fileType: image/png; the spoofed type is not on
the dangerous-MIME deny-list, so the dangerous-content scan was skipped and the file
was stored, yielding stored XSS served under the WeKan origin (CWE-434).
Fix: the client-supplied type can no longer gate the safety scan. When content-based
detection via 'file' is unavailable, fall back to a dependency-free JS content sniff
(looksLikeDangerousMarkup) that inspects the real bytes for HTML/SVG/XML/<script>
signatures and forces the dangerous-content scan regardless of the claimed MIME, so a
spoofed image/png that is really HTML+JS is rejected. The sniff matches only definitive
markup, so genuine binary uploads (real PNG/JPEG/PDF, incl. large ones) are unaffected.
Also log a one-time warning when 'file' is missing (previously silent).
Regression test server/lib/tests/fileValidationBypass.security.tests.js covers the
spoofed dangerous uploads and safe binaries.
CVSS:3.1 8.3 High (AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N). Thanks to HNUfwj and xet7.
Disabling activities/notifications/watch can serve any law or policy, not only
GDPR. Remove GDPR mentions from the code comments and the en.i18n.json toggle
descriptions (and the Admin Panel docs), keeping the neutral #5820 reference.
A card description was recorded in the activity log (a-changedDescription, #5482)
but never added to the outgoing-webhook / notification params, so integrations got
an event with no description text.
The Activities.after.insert payload now sets params.description (the card's current
description, only when non-empty) for every card event, and forwards the activity's
oldValue/value alongside the existing timeValue/timeOldValue so a description change
carries the before/after text. New fields are additive and backward-compatible.
Impersonation events are already recorded in the impersonatedUsers collection
whenever an admin impersonates a user (e.g. to export a private board). Surface
them as a new admin report, newest-first, with the same server-side search +
pagination as the other reports.
- server/publications/impersonationReport.js: impersonationReport publication
(admin-only, sort createdAt -1, limit/skip, $or search over admin/user/board/
attachment ids and reason) + getImpersonationReportCount method. Also publishes
the referenced admin/impersonated user docs (same fields the People panel uses)
so usernames resolve and the Edit user popup has its data.
- adminReports.jade/.js: new Impersonation side-menu entry, sub-template (Date,
Admin, Impersonated user, Board, Reason), pagination + search wired through the
shared reportConfig. Clicking a username opens the same editUser popup as
Admin Panel / People.
- i18n: impersonationReportTitle, impersonation-admin, impersonation-user, reason.
- server/lib/tests/importExportSecurity.tests.js: positive and negative unit
tests for the anonymization helpers (map building, user-doc scrubbing, @mention
rewriting that ignores unknown handles and email addresses, requestedBy/assignedBy
identity replacement, and safe no-ops on empty input).
- docs/Features/Admin-Panel/Admin-Panel.md: new Features tab section documenting the
Performance, Security (rich-text hardening + import/export privacy) and
Notifications (GDPR) toggles.
New Notifications category with three GDPR toggles (all default off), enforced
server-side:
- Disable all activities: activity-feed entries are neither recorded
(Activities.before.insert returns false to cancel) nor shown (the activities
publication returns nothing, hiding existing and new entries).
- Disable all notifications: the Activities.after.insert dispatch hook returns
early, so no watch notifications are sent; activity recording is unaffected.
- Disable watch: the watch() method rejects any watch-level change, and the board
header watch button is hidden.
A synchronously-readable server cache (models/lib/featureFlags.js, kept current by
a Settings observer) lets the sync before.insert hook read the flags without
awaiting. Adds settings disableActivities, disableNotifications, disableWatch,
published in the public setting, plus global Blaze helpers activitiesDisabled /
watchDisabled for UI hiding.
Six new optional toggles (all default off) governing how boards and user data
cross the WeKan boundary, enforced server-side so they cannot be bypassed from
the client:
- Disable all import / Disable all export: master switches that turn off every
import/export feature. importBoard and cloneBoard call assertImportEnabled;
every Exporter build()/buildStream() call assertExportEnabled. The import and
export menu options are hidden in the UI via global importDisabled/exportDisabled
Blaze helpers.
- Disable import avatars / Disable export avatars: never carry avatars into/out of
WeKan. Import is gated at the single localizeAvatarFromBuffer choke point (covers
WeKan JSON import, LDAP, OIDC/OAuth2 login sync and board-open localization) plus
Trello inlineMemberAvatars; export skips the base64 avatar embed + avatarUrl in
both Exporter paths.
- Anonymize import users / Anonymize export users: replace username/fullname/initials
with counter placeholders (user1, user2, ...), drop avatars, and rewrite @username
mentions + requestedBy/assignedBy in card/comment text. The placeholder word "user"
is translated to the current user language. Export covers both build() and the
streaming buildStream() (which does an id-only pre-scan so mentions streamed before
the users array resolve to matching labels); import scrubs the incoming board in
WekanCreator before any placeholder user or card is created.
New shared server helper models/lib/importExportSecurity.js holds the settings
read, guards, anonymization map builder and text rewriter. Adds settings
disableAllImport, disableAllExport, disableImportAvatars, disableExportAvatars,
anonymizeImportUsers, anonymizeExportUsers, published in the public setting.
Translate the new render-links-as-plain-text-description, always-show-code-as-text
and always-show-code-as-text-description strings to Finnish, matching existing
terminology (tarkistuslistat, klikattava, 'Kun käytössä...', 'Oletuksena pois
käytöstä...').
New optional toggle under Admin Panel / Features / Security. When enabled,
rich text is never rendered as markdown or HTML -- the entire source is shown
as escaped plain text in every rich text field (board and card titles,
descriptions, comments, checklists, etc.), so hidden content is always
revealed: HTML comments (<!-- -->), the target URL inside a markdown link,
JavaScript and any other code. All code is always visible, not clickable, and
not running.
This extends the existing invisiblebleed protection (which already showed raw
source for description-less markdown links) to all content, and complements
the "Render links as plain text" toggle.
Implementation:
- New global setting alwaysShowCodeAsText (models/settings.js), published in
the public setting publication, default off.
- Admin Panel / Features / Security gains a second materialCheckBox toggle.
- The markdown helper has the raw text, so the decision lives there. Because
the wekan-markdown package cannot import app code, the setting is bridged via
a ReactiveVar on the exported Markdown object; the rich text viewer
(editor.js) keeps it in sync with the setting reactively, and the markdown
helper reads it and renders the fully HTML-escaped source in a <pre> when on.
Full escaping (not DOMPurify stripping) ensures tags like <script> are shown
as text rather than removed. The description-less-link branch now uses the
same full escaping so it too reveals all source.
New optional security feature under Admin Panel / Features / Security. When
enabled, all links -- both markdown links like [label](url) and raw HTML
<a href> tags -- are always shown as plain, non-clickable text in every rich
text field (board and card titles, descriptions, comments, checklists, etc.),
so a link can never be clicked and cannot present misleading anchor text.
This is a hardening option on top of the existing XSS sanitization (which
already strips javascript:/data: schemes, event-handler attributes and
dangerous tags); it addresses #6453, where a board title rendered as a
clickable link. Default off, so links stay clickable.
Implementation:
- New global setting renderLinksAsPlainText (models/settings.js), published in
the public setting publication.
- Admin Panel / Features gains a Security category with a materialCheckBox
toggle that saves the setting immediately.
- The shared DOMPurify sanitizer takes a { stripLinks } option that forbids the
<a> tag while keeping its inner text (KEEP_CONTENT), so links collapse to
plain text. The rich text viewer (mentions helper in editor.js) passes
stripLinks based on the setting, gated reactively so toggling re-renders.
On Sandstorm the grain owner (Sandstorm 'configure' permission) maps to a
WeKan admin, which gates the Admin Panel and its Attachments / Sandstorm
cleanup tools. A new grain worked because Users.after.insert derives the role
for the freshly inserted user, but a grain migrated from an older WeKan
already contains the user, so that insert hook never runs. Sandstorm
auto-login uses connection.setUserId() (bypassing accounts-base, so
Accounts.onLogin never fires), and the remaining observeChanges hook on
services.sandstorm only fires when that field actually changes on login. When
the migrated user's stored permissions already equal the grain's current
permissions, the login $set is a no-op with no oplog entry, so isAdmin was
never derived and the owner had no Admin Panel.
Reconcile at grain startup (a migrated grain reboots once migration
completes): grant WeKan admin to every Sandstorm user whose stored
permissions include 'configure'. Promote only, never revoke here (that is the
change hook's job on a real permission change), so a stale/empty stored
permission set can never lock the owner out of the Admin Panel.
The storage engine was read only from serverStatus, which requires the
cluster-level clusterMonitor role. A per-database WeKan user (readWrite on
the wekan db only, as in docs/Platforms/FOSS/Docker/Meteor3/) is not
authorized to run it, so it was rejected and the field stayed 'unknown'.
Fall back to a $collStats aggregation, which needs only the collStats action
that read/readWrite already grant, and read the real engine (wiredTiger /
inMemory) from storageStats. The MongoDB compatible version and Database
commit were already correct: they come from buildInfo, which needs no
special privileges.
The postinstall script (scripts/patch-yargs-dirname.cjs) added in 6b409c5da
to fix the Meteor/Mocha test boot crash makes npm mark the root package with
hasInstallScript: true. Sync the lockfile to match package.json.
A low-privilege (comment-only / read-only) board member could escalate to
board admin and take over a private board via the board 'sort' collection
allow rule. To support drag-to-reorder, a second Boards.allow({ update })
rule returned true for any board member whenever the update touched the
'sort' field. Meteor applies the WHOLE modifier once any allow rule approves
and no deny rule rejects, and does not scope the approving rule to the field
that satisfied it. Because canUpdateBoardSort only checked that 'sort' was
AMONG the modified fields, a restricted member could smuggle arbitrary board
mutations (members, permission, title) into the same $set as 'sort' in one
DDP Boards.update call, making themselves admin, flipping the private board
to public, and evicting the legitimate owner. The last-admin deny rule only
inspected $pull, so a wholesale $set of the members array bypassed it.
Fix: restrict canUpdateBoardSort so the sort-reorder rule approves an update
only when 'sort' is the sole modified field. Defense in depth: the last-admin
deny rule now also rejects a $set rewrite of the members array that would
drop the last active admin. Regression test covers the multi-field smuggling
case. The legitimate All Boards drag-reorder is unaffected: it persists order
per-user in profile.boardSortIndex, not in the board document.
CVSS:3.1 8.8 High (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), CWE-863, CWE-269.
Thanks to 5ud0 / Tarmo Technologies and xet7.
- .github/workflows/meteor-spk.yml: assembles WeKan's modernized meteor-spk (the
packaging tool + its meteor-spk.deps: Node 24, FerretDB, Mongo 3.x CLIs, modern
sandstorm-http-bridge) via sandstorm-src/build-deps.sh — reusing sandstorm.yml's
setup — and zips it as meteor-spk-YYYY-MM-DD_HH_MM_SS.zip, the same kind of
self-contained bundle sandstorm-io/meteor-spk releases but with WeKan's deps baked in.
Uploaded as an artifact and to the newest GitHub Release. Needs no keyring (it does
not pack/sign a .spk).
- .github/workflows/sandstorm-store.yml: publishes an already-built .spk to the
Sandstorm App Market. Installs Sandstorm + assembles meteor-spk and restores
SANDSTORM_KEYRING like sandstorm.yml, downloads the newest .spk from the WeKan release
(built and attached by sandstorm.yml), renames it to wekan-<VERSION>.spk (VERSION from
the release tag, e.g. 9.88, overridable via inputs), and runs 'spk publish
wekan-<VERSION>.spk' exactly like releases/release-sandstorm.sh. Does not rebuild the
.spk.
Thanks to xet7.
The crash moved from yargs/lib/platform-shims/esm.mjs to yargs/build/lib/utils/
apply-extends.js (import.meta.resolve(config.extends)) — yargs' ESM build has more than
one file using import.meta. Rewrite the workaround to scan the whole node_modules/yargs
tree and rewrite every ESM-only construct (import.meta.url/.resolve/.dirname/.filename,
const require = createRequire(...), and yargs' own const __dirname) to the CommonJS
wrapper equivalents in one pass, so a new yargs file can't reintroduce the boot crash.
yargs is never executed at runtime here, so only valid CommonJS parsing matters.
Thanks to xet7.
Renaming only __dirname was not enough: yargs' esm.mjs also uses import.meta.url (invalid
in Meteor's CommonJS module wrapper -> 'Cannot use import.meta outside a module') and
redeclares require via createRequire(import.meta.url) (collides with the wrapper's
require). reify rewrites the file's import statements but not import.meta. Rewrite all
three to use the wrapper's __filename / __dirname / require, which yargs never actually
exercises here (it is only bundled, never called). Idempotent; also patches a file left
half-rewritten by the previous version of this script.
Thanks to xet7.
.meteorignore does not apply to node_modules under Meteor 3 / rspack (verified: the
rebuilt Mocha bundle still contained node_modules/yargs), so revert that no-op rule and
fix the actual crash instead.
Root cause (pre-existing, unrelated to app code): the whole yargs package gets pulled
into the server bundle as a transitive devDependency, and its ESM shim
node_modules/yargs/lib/platform-shims/esm.mjs declares a top-level
'const __dirname = fileURLToPath(import.meta.url)'. Meteor wraps that .mjs in a CommonJS
module function that already provides __dirname, so it collides —
'SyntaxError: Identifier __dirname has already been declared' — crashing the server
bundle at boot, which is why Mocha reported 0 tests.
Add scripts/patch-yargs-dirname.cjs, run from a package.json postinstall, which renames
yargs' local __dirname (and its .substring/.lastIndexOf uses) to __dirnameYargs so it can
no longer collide with the wrapper's. Idempotent and best-effort (never fails install);
yargs is not used at runtime here so the rename is inert for the app.
Thanks to xet7.
'meteor test' (Mocha) crashed at boot with 'Identifier __dirname has already been
declared'. Root cause is unrelated to app code: node_modules/yargs/lib/platform-shims/
esm.mjs declares a top-level 'const __dirname = fileURLToPath(import.meta.url)', which
collides with the __dirname that Meteor's CommonJS module wrapper already provides. yargs
gets pulled into the bundle only because i18next-sprintf-postprocessor (imported by
imports/i18n/tap.js) ships a stray rollup.config.js that does require('yargs'), and a
devDependency (mongodb) has since installed yargs 18 into node_modules so that require now
resolves. That build config is not part of the package's runtime entry
(index.js -> dist/commonjs), so exclude it from Meteor's bundle via .meteorignore.
Pre-existing (the same boot crash happened before this branch's test work) and independent
of the avatar/import-export feature.
Thanks to xet7.
Two build/load fixes surfaced by running the full test suite:
- server/imports.js: import the new server-only files so they actually load. In
mainModule mode a file not imported here never loads, so Accounts.onLogin avatar
localization (server/avatarLocalizationOnLogin.js) and the imported-user reconciliation
Meteor methods (server/importedUserReconciliation.js) would silently never register.
- Test __dirname collision: 'meteor test' crashed at boot with 'Identifier __dirname has
already been declared'. The client test index (client/lib/tests/index.js) loads
boardTriggersClass.tests.js, which referenced the bare __dirname global; under
meteor test that makes Meteor inject a colliding with its CommonJS
wrapper's, aborting the whole server bundle (the same failure already fixed once in
dependencies.openapi.tests.js — this was the next file to trip it). Replace __dirname
with a process.cwd()/PWD walk-up in boardTriggersClass.tests.js, and defensively in the
node-run tests/rtl.test.js, tests/stickers.test.js and tests/stickers.packs.test.js too.
Thanks to xet7.
Split the testable, security- and correctness-critical logic of the new avatars +
original-members feature into pure Node modules (module.exports, no Meteor) and cover them
with plain-Node tests/*.test.cjs (positive AND negative), matching the repo's existing
unit-test style. Wired into the test:unit:node script.
- models/lib/avatarUrlSafety.js (from server/lib/localizeAvatar.js): isExternalAvatarUrl,
isBlockedIp (SSRF ranges), decodeDataUri, checkUrlHostSync. Tests assert external vs
local/relative/non-http URLs, that private/loopback/link-local/CGNAT/metadata/multicast
IPv4+IPv6 (incl. IPv4-mapped) are blocked while genuine public addresses and near-miss
ranges are allowed, data: decoding, and that non-http(s) schemes, localhost and
metadata hosts are rejected.
- models/lib/importedUserReconciliationPlan.js (from server/importedUserReconciliation.js):
planReconciliation. Tests: matches merge, non-matches deactivate, never match another
placeholder or self or a username-less placeholder.
- packages/wekan-ldap/server/ldapPhoto.js (from sync.js): getLdapPhotoBuffer. Tests the
Buffer / array / {type:'Buffer'} / base64 shapes and jpegPhoto>thumbnailPhoto, and that
missing/empty/short values yield null (never throw).
- models/lib/importedBoardMemberPlan.js (from wekanCreator.js): planImportedBoardMember.
Tests: unmapped member kept by original id but inactive+non-admin, mapped role preserved,
importer and id-less members dropped.
The extractions are behaviour-preserving; the app modules now import these helpers.
Thanks to xet7.
Make it obvious which board members are backed by a real account and which are not,
both on card avatars and in the right sidebar member list.
- userAvatar (js/jade/css): the avatar gets an 'imported-member' class (dashed grey ring
+ amber '?' corner badge) for un-reconciled board-import placeholders
(authenticationMethod:'imported'), and an 'inactive-member' class (greyscale + dim +
grey badge) for members deactivated on the board (e.g. a person not in LDAP after
reconciliation). A placeholder is usually both; a real active account gets neither. The
tooltip explains the state.
- boards.js membersForSidebar(): active members first (as before) then the inactive /
imported ones appended, and sidebar.jade uses it, so the member list shows EVERYONE and
which are active vs not instead of hiding inactive members.
- i18n: imported-member-no-account, inactive-member.
Thanks to xet7.
server/importedUserReconciliation.js turns the inert import placeholders into the right
real members deliberately, after import — never auto-mapped during import.
- reconcileImportedUsers(): for each authenticationMethod:'imported' placeholder, find a
real account with the same username (not another placeholder) — the valid accounts are
whatever real WeKan accounts exist, typically provisioned by LDAP/OIDC at login — and
merge the placeholder into it; if none exists (e.g. the person is not in LDAP) leave the
placeholder and its board memberships inactive (isActive:false).
- mergeImportedUserInto(placeholderId, targetId): reassign every reference (board.members,
card.members, card.assignees, activities.userId, cardComments.userId) from the
placeholder to the target, reusing the target's membership if it already is a member,
then remove the placeholder.
- Admin-only Meteor methods reconcileImportedUsers and mergeImportedUser(placeholderId,
targetId) for the automatic sweep and for one-off deliberate mapping.
Because reconciliation matches against existing real accounts (which LDAP populates on
login) it needs no direct LDAP query and is provider-agnostic. Merges reassign by the
preserved original _id, so nothing is lost.
Thanks to xet7.
Importing a WeKan board no longer collapses unmapped members onto the importing user (a
wrong mapping attaches the wrong person and can leak board permissions). Instead each
original member carried in board.users becomes an inert placeholder user:
- createPlaceholderUsers() reuses the ORIGINAL _id, so every card/comment/activity
member reference resolves to the right person with no remapping, and populates
this.members as an identity map (id -> id) so _user() keeps the original member.
- Placeholders are created with Users.direct.insertAsync (bypassing the after.insert
hooks — Sandstorm identity sync and the disableRegistration/invitation-code gate that
would otherwise reject a non-account user), marked authenticationMethod:'imported',
loginDisabled:true, isActive:false, and carry NO password or email. Username collisions
suffix the placeholder's name so an existing account is never renamed/stolen.
- The member's avatar (embedded as base64 by the exporter) is restored into files/avatars
via the localizer, so the original picture shows and is exportable again (Sandstorm too).
- Board membership adds imported members inactive and non-admin, so they are visible but
hold no permissions until deliberately reconciled later; the importer stays sole admin.
Also guard the Sandstorm Users.after.insert hook to no-op on users without
services.sandstorm (placeholders), which otherwise threw reading preferredHandle.
Mapping/merging to real accounts and LDAP reconciliation are a later, deliberate step.
Thanks to xet7.
Board export already carried the original members' username, fullname and initials (the
field whitelist excludes passwords, emails and services). Now, for each member whose
avatar is a local WeKan file, embed the file itself as base64 (profile.avatarFile +
avatarFileName + avatarFileType) alongside the existing avatarUrl reference, in both the
in-memory build() and the streaming buildStream() paths.
Because this reads a local avatars file (no outbound fetch), it works inside a Sandstorm
grain too: a board that already has many stored avatars can be exported with every
member's picture intact, ready to re-import elsewhere. External, not-yet-localized
avatars are still exported as their URL only (Increment 1 localizes those into files
first, on board open / at login).
Thanks to xet7.
Second set of triggers so external avatars from identity providers become local WeKan
avatars (files/avatars), shown in WeKan and carried by board export/import.
- LDAP (packages/wekan-ldap/server/sync.js): syncUserData now reads the binary
jpegPhoto / thumbnailPhoto (tolerating Buffer / array / {type:'Buffer',data} / base64
shapes) and, unless the user already has a locally-stored avatar, stores it as a
self-contained data: URI in profile.avatarUrl. That displays immediately and needs no
coupling from this package to app code; the app then materialises it to a real file.
- OIDC (packages/wekan-oidc/oidc_server.js): capture the standard claim (with
an OAUTH2_AVATAR_MAP override) into serviceData and set profile.avatarUrl for new users.
- App (server/avatarLocalizationOnLogin.js): Accounts.onLogin localizes the logging-in
user's external avatar immediately (provider-agnostic), complementing the board-open
trigger. Fire-and-forget, idempotent, never blocks login. (Inside a Sandstorm grain
outbound fetch is sandboxed, so a Sandstorm profile picture is a best-effort no-op here
and needs client-assisted capture — a later step.)
Thanks to xet7.
First trigger for external-avatar localization: the single-board publication
(publishComposite('board')) now fires a best-effort, fire-and-forget
localizeBoardMemberAvatars(boardId). For every member whose profile.avatarUrl points
outside WeKan, it copies the image into WeKan's own files/avatars (via the SSRF-guarded
helper) and repoints avatarUrl at the local copy. Idempotent (already-local avatars are
skipped) and it never blocks or delays the publication.
This is the universal catch-all: no matter how a member's avatar became external
(OAuth2/OIDC picture URL, gravatar, a pasted URL), opening the board makes it a local,
exportable WeKan avatar. (Note: inside a Sandstorm grain outbound fetch is sandboxed, so
Sandstorm profile pictures need the provider-side capture added next; LDAP jpegPhoto is
binary and is imported at login, also next.)
Thanks to xet7.
First piece of making external avatars (Sandstorm profile pictures, LDAP jpegPhoto,
OAuth2/OIDC picture claims, gravatar, any URL/data-URI) into local WeKan avatar files
under WRITABLE_PATH/files/avatars, so they display without the identity provider and are
carried by board export/import.
server/lib/localizeAvatar.js:
- isExternalAvatarUrl(url): true unless already a local /cdn/storage/avatars/ (or legacy
/cfs/files/avatars/) URL.
- localizeAvatarFromBuffer(userId, buffer, {type,name}): write bytes into the Avatars
FilesCollection (onAfterUpload sets the user's local profile.avatarUrl).
- localizeAvatarFromUrl(userId, url): fetch (or decode a data: URI) then store.
- localizeUserAvatarIfExternal(user): idempotent no-op when already local.
Every network fetch is SSRF-guarded: http/https only; the host is resolved and any
private, loopback, link-local, CGNAT, multicast or cloud-metadata (169.254.169.254)
address is refused; 8s timeout; 5 MB cap; image content-type only. Not wired to any
trigger yet (board-open / export / login flows come next).
Thanks to xet7.
Now that the grain boots, logs in, lists/opens boards, uploads/downloads attachments,
and migrates an old MongoDB 3 grain end to end, drop the two temporary diagnostics:
- models/attachments.js: revert the Meteor-Files debug flag to false (it was enabled on
Sandstorm to trace the upload 'session expired [408]' issue and was spamming the grain
log with the full FilesCollection dump and every find()).
- server/ferretdbQueryDebug.js: remove the mongodb Collection.find wrapper that logged
FerretDB-rejected selectors (used to find the $elemMatch 'unknown operator: userId'
issue, since fixed in wekan/FerretDB).
Thanks to xet7.
Two UX requests once the migration itself works end to end:
- Auto-open All Boards. Previously the dashboard sat on the grain URL for 60s after
completion and the admin had to reload to reach WeKan. On success the importer now
exits after ~5s (long enough for the browser to fetch the done page), and the done
page runs a JS poller that fetches '/' until WeKan's app shell answers (tolerating the
brief importer->WeKan port hand-off gap) and then location.replace('/') opens All
Boards. The spinner keeps spinning through the hand-off so it is clear the grain is
still working; no meta-refresh on the done page (a refresh mid-hand-off would hit a
dead port). On failure it still stays up a minute with the errors.
- WeKan colours. Recolour the dashboard from the dark scheme to WeKan's blue/white/grey
(belize blue #2980b9 headings and spinner, white card on light-grey background, grey
borders, system font).
Thanks to xet7.
With text collections migrating, the 3 attachments still produced 0 extracted files and
errors like 'parse attachments.chunks: Unexpected Binary Extended JSON format
{"$binary":"iVBOR..."}'. Two causes, both fixed:
1. Legacy Extended JSON v1 binary. mongo 3.x mongoexport writes binary as
{"$binary":"<b64>","$type":"00"} (v1), but modern bson EJSON.parse only
accepts v2 {"$binary":{"base64":...,"subType":...}}. Rewrite v1 -> v2 per line
before parsing, so chunk data (and any binary in text collections) parses.
2. Meteor-Files native GridFS buckets were unhandled. The grain stores attachments in
attachments.files + attachments.chunks (FilesCollection record in the attachments
collection), not CollectionFS's cfs_gridfs.*. Reassemble those buckets to disk,
linking each GridFS file to its record via metadata.fileId/versionName, then repoint
the migrated record's versions.<v> at the file and DROP versions.<v>.meta.gridFsFileId
— otherwise WeKan's getFileStrategy keeps choosing the (now-empty) GridFS backend and
the image 404s. Also exclude <bucket>.files/.chunks (and tempstores) from the text
migration so binary chunks are no longer run through EJSON as documents.
Thanks to xet7.
Text collections exported and 'inserted N/N' was logged, but every document actually
failed with 'Unsupported OP_QUERY command: update' — nothing reached FerretDB. Cause:
requireAny('mongodb') resolved the ANCIENT meteor-spk base driver (v2.x, at the deps
root) because the modern driver is not directly under programs/server/npm/node_modules
— Meteor nests it at .../meteor/npm-mongo/node_modules/mongodb (v6.16). The 2.x driver
speaks legacy OP_QUERY, which FerretDB rejects; the 6.x driver speaks OP_MSG (the same
driver the WeKan app uses against FerretDB). Add the npm-mongo path as the first
resolver anchor, and log the resolved driver version.
(Separately, GridFS attachment/avatar extraction still finds 0 files for this grain —
its attachments appear to be in Meteor-Files buckets (attachments.files/.chunks) rather
than the CollectionFS cfs_gridfs.* the importer currently handles; to be addressed once
the modern driver confirms text migration and the real attachment collection counts.)
Thanks to xet7.
Link the mongodb default-import, mongoexport --quiet removal, diagnostic/dashboard, and
createRequire commits inline within their parent migration bullets.
Thanks to xet7.
The EJSON diagnostic was conclusive: require('bson') returned an object with no EJSON,
mongodb.EJSON was undefined, and mongodb/lib/bson* were MODULE_NOT_FOUND. Cause: the
importer sits at the deps root next to the OLD meteor-spk 0.6.0 base node_modules
(bson 1.x with no EJSON at all, plus an ancient mongodb that has MongoClient but no
EJSON re-export), kept there only for the niscu->3.0 stage — so a bare require resolved
those adjacent copies. WeKan's current bson/mongodb (with EJSON) live under
programs/server/npm/node_modules. Anchor createRequire inside that modern bundle first
(falling back to the deps root), and load both mongodb and bson through it. This also
switches the importer to the modern mongodb driver — the same one the WeKan app uses
against FerretDB.
Thanks to xet7.
The mongodb default import exposed MongoClient but NOT EJSON (mongodbPkg.EJSON was
undefined), so the previous 'take EJSON from mongodb' attempt still hit the FATAL
guard. Node 24's ESM default-interop for these CommonJS packages drops the
getter/re-export used for EJSON. Switch to createRequire (CJS require returns the real
module.exports with getters intact and honors NODE_PATH), and resolve EJSON by trying,
in order: mongodb.EJSON, mongodb/lib/bson.js, mongodb/lib/bson, bare bson's .EJSON,
and bare bson itself — falling back with a diagnostic list of what each attempt
returned so a remaining failure names the cause instead of just 'undefined'.
Thanks to xet7.
With mongoexport connecting, every collection then failed with 'parse <coll>: Cannot
read properties of undefined (reading parse)' — EJSON was undefined. The importer runs
with NODE_PATH=programs/server/node_modules, but the EJSON-bearing bson (7.3.0) lives
under programs/server/npm/node_modules, so a bare 'import bson' did not resolve to it
and EJSON came out undefined. The mongodb driver (which resolves fine — MongoClient
works) bundles bson and re-exports EJSON from lib/bson.js, so take EJSON from the same
default import and drop the separate bson dependency. Add an upfront guard that fails
loudly if EJSON.parse is ever missing instead of spamming one error per collection.
Thanks to xet7.
The real reason every mongoexport failed (revealed once --quiet was dropped):
'error connecting to db server: no reachable servers'. mongoexport is a Go tool
whose --host defaults to 'localhost', which resolves to ::1 (IPv6) first, but the
migration mongod listens only on --bind_ip 127.0.0.1 (IPv4) — so mongoexport could
never reach it, while the mongo shell (whose host defaults to 127.0.0.1) connected
fine and listed all 42 collections. Pass --host 127.0.0.1 explicitly.
Also fill the dashboard Activity panel from the first moment (mongoexport-ready line,
and one line per collection including empty ones) so progress is visible live instead
of the panel sitting on '(waiting…)' while only red connection errors accumulated.
Thanks to xet7.
The --version probe confirmed the bundled mongoexport runs fine (r3.2.22), yet every
per-collection export exited status=1 with empty stderr AND stdout. The empty stderr
was mongoexport's own --quiet flag suppressing its failure message. Drop --quiet so
the real reason (e.g. 'Failed: <reason>') prints to stderr; mongoexport's normal
progress lines also go to stderr, so stdout stays clean Extended JSON either way.
Also surface progress on the dashboard as the user asked: a rolling Activity log
(last ~15 lines: collections found, per-collection export/insert counts, GridFS file
extraction counts) rendered in a panel and mirrored to the grain log, so it is clear
what the migration is doing rather than only red errors appearing later.
Thanks to xet7.
Every per-collection mongoexport failed with 'failed: undefined' because the error
only logged (r.stderr || r.error): an empty stderr with a non-zero/killed status
(e.g. a SIGSEGV, where spawnSync reports status=null, signal='SIGSEGV', stderr='')
printed as 'undefined', hiding the real cause. Log a full describe(r) instead
(status, signal, error code, stderr AND stdout snippets), and probe
'mongoexport --version' / '--help' once at startup so the next run shows whether the
bundled mongoexport binary itself is broken (dies on --version too → an ABI/bundling
problem) or only the export invocation is. The mongo shell on the same libs works
(listCollections succeeds), so this narrows it precisely.
Also make the progress dashboard obviously live: a CSS spinner while running (✅/❌
when done), a server 'updated' timestamp that changes on every 2s auto-refresh, and
an error counter — the previous page refreshed but showed no sign of activity.
Thanks to xet7.
Same CommonJS/ESM interop issue as the bson import: with { EJSON } fixed, the
importer next threw 'Named export MongoClient not found. The requested module
mongodb is a CommonJS module'. The bundled mongodb driver is CommonJS under Node
24's ESM loader, so import the default and destructure MongoClient. These are the
only two third-party imports; the rest are node: builtins.
Thanks to xet7.
With the WiredTiger cache fixed, mongod 3.0 now starts and the migration importer
runs, but it crashed immediately: 'import { EJSON } from "bson"' threw
"SyntaxError: Named export 'EJSON' not found. The requested module 'bson' is a
CommonJS module". bson (as bundled in WeKan's server node_modules) is CommonJS, so
Node 24's ESM loader exposes no named exports on it. Import the default and
destructure EJSON from it, as Node's own error message advises. Shared by the Snap
migration too (same Node 24).
Thanks to xet7.
mongod 3.0.7 parses --wiredTigerCacheSizeGB as an integer number of GB, so the
0.25 from the previous commit failed at startup with 'Error parsing option
wiredTigerCacheSizeGB as int: Bad digit "." while parsing 0.25' and the migration
still crash-looped. Use 1 (GB). It is a cache cap, not a preallocation, so a short
migration of a normal-sized grain never actually uses that much.
Thanks to xet7.
Importing an existing WeKan grain crash-looped in the one-time MongoDB 3 -> FerretDB
migration: mongod 3.0 forked and its child aborted with exit code 14. Two bugs:
1. WiredTiger cache_size=0G. mongod 3.0 sizes the WiredTiger cache from detected
RAM (RAM/2 - 1GB), but inside a Sandstorm grain sandbox RAM detection returns 0,
so it computes cache_size=0G and WiredTiger refuses to open (minimum is 1MB),
logging 'Value too small for key cache_size' and 'Fatal Assertion 28561' to
/var/migration-mongod.log before aborting. Pass an explicit
--wiredTigerCacheSizeGB 0.25 (256MB) to both mongod invocations (the niscu ->
3.0 stage, which writes new WiredTiger data, and the 3.0 -> FerretDB stage) so
the cache size never depends on RAM detection. The data itself is fine (turtle
file: WiredTiger 2.5.3, i.e. written by mongod 3.0; the 'unclean shutdown'
notice is harmless, WiredTiger recovers from the last checkpoint).
2. Wrong source database. Sandstorm WeKan grains store their data in the
Meteor-default database 'meteor' (the niscu stage reads/writes 'meteor', and a
real grain's WiredTiger catalog shows meteor.* collections), but the importer
was told SRC_DB 'wekan', so even once mongod started it would have exported zero
collections. Only the FerretDB target database is 'wekan'.
Thanks to xet7.
Two grain-navigation regressions vs the last working Sandstorm build (v6.15):
1. Opening a grain showed 'Must be logged in' instead of the All Boards page.
On Sandstorm the platform authenticates the user asynchronously over DDP via
connection.setUserId(), which (unlike a password login) does not set
Meteor.loggingIn(), so Meteor.userId() is null for the first moments after the
grain opens. useraccounts' ensureSignedIn route trigger and renderBoardList()
both bounced that brief null window to the atSignIn route — a sign-in page that
does not exist inside a grain. config/router.js now uses a Sandstorm-aware
ensureSignedInUnlessSandstorm wrapper (a no-op on Sandstorm) and renderBoardList()
no longer redirects on Sandstorm; the All Boards list renders and reactively
fills in once the platform login lands.
2. The Sandstorm shell's outer grain URL did not update when switching boards. The
shell rewrites /grain/<id><path> when the app posts a { setPath } message
(sandstorm shell/imports/client/grain-client.js). The sync was a bare top-level
Tracker.autorun that could run before flow-router-extra's reactive path tracking
was initialised and then never re-run. Restore v6.15's event-driven
FlowRouter.triggers.enter (fresh entering path, no dependency on init order) and
additionally keep a watchPathChange() autorun wrapped in Meteor.startup as a
backup. setTitle now also re-runs on route change.
Thanks to xet7.
On Sandstorm the grain download route returned 403 for private boards, so
attachment thumbnails, minicard covers and the slideshow all showed broken
images even though the upload succeeded and the file was on disk. The download
handler (server/routes/universalFileServer.js) authorizes private-board files
via a Meteor login token (Authorization / X-Auth-Token / authToken query /
meteor_login_token cookie), but Sandstorm has none of these: authentication is
via connection.setUserId() and the sandstorm-http-bridge X-Sandstorm-* request
headers, so extractLoginToken() returned null and isAuthorizedForBoard() denied
every request. Sandstorm already gates grain access at the platform level, so any
request reaching WeKan is an authenticated grain user; trust it. Both
isAuthorizedForBoard() and isAuthorizedForAvatar() now short-circuit to allow
when Meteor.settings.public.sandstorm is set and the request carries the
bridge-injected X-Sandstorm-User-Id header. Gating on the setting means a spoofed
header cannot bypass auth on non-Sandstorm deployments.
Thanks to xet7.
Link the fix that switches attachment uploads to DDP transport on Sandstorm, since
the bridge strips Meteor-Files' custom x-* HTTP upload headers.
Thanks to xet7.
Adding a file to a card in the grain failed with HTTP 400 "Can't continue upload,
session expired [408]" and the file silently disappeared. The Meteor-Files HTTP
upload protocol signals the first chunk with an x-start header and tracks the
session with x-mtok / x-chunkid / x-fileid / x-eof, but Sandstorm's request-header
whitelist (web-session.capnp) does not include those, so the sandstorm-http-bridge
strips them: the server never sees x-start, treats every request as a chunk
continuation, cannot find the per-fileId session and returns 408. Use
transport: 'ddp' on Sandstorm (detected via Meteor.settings.public.sandstorm) so
uploads go over DDP method calls instead of custom HTTP headers; HTTP transport is
kept everywhere else (it avoids the Safari DDP-reconnect stall).
Thanks to xet7.
Attachment uploads in the grain fail with HTTP 400 "Can't continue upload, session
expired [408]": the upload start succeeds but the per-fileId session is gone by the
time a chunk arrives (both the in-memory _currentUploads entry and the
__pre_attachments pre-collection doc are missing), which points at the polling
observe (FerretDB has no oplog) firing a spurious removed event and aborting the
upload. The Attachments FilesCollection had debug: false, so nothing about the
upload path is logged. Enable Meteor-Files debug on Sandstorm only (gated on
Meteor.settings.public.sandstorm) so the grain debug log shows the start /
createStream / observer / continueUpload steps and pinpoints where the session is
lost. TEMPORARY: revert to debug: false once the upload is fixed.
Navigating between boards worked but the Sandstorm shell's grain URL never updated
(it stayed on the grain root), unlike standalone WeKan. The path was synced via a
global FlowRouter.triggers.enter callback, which does not fire reliably on client
navigation in this flow-router-extra / Meteor 3 setup. Sync it from a reactive
Tracker.autorun on FlowRouter.watchPathChange() instead (the same mechanism the
setTitle sync already uses), so every route change posts setPath to the shell and
the grain URL becomes /grain/<id><path>.
Thanks to xet7.
Opening a board in the grain fails with "MongoServerError: unknown operator: userId"
(BadValue) - FerretDB rejecting a query MongoDB accepts - but the driver stack trace
has no WeKan call site, so the offending selector is unknown. This wraps the raw
mongodb Collection.find() to log the collection name and exact selector whenever a
cursor iteration throws, to pinpoint the query. TEMPORARY: to be removed once the
query is rewritten FerretDB-compatibly.
Thanks to xet7.
The Sandstorm login was actually succeeding - Meteor.userId() gets set (confirmed:
Meteor.connection._userId held a valid id, Meteor.loggingIn() false) - but the grain
stayed on the sign-in page. WeKan's home route (renderBoardList) checks
Meteor.userId() once and, because the Sandstorm header login is asynchronous and
uses connection.setUserId() (bypassing accounts-base, so no Accounts.onLogin fires),
finds it still null on first render and redirects to 'atSignIn' - where the user is
stranded even after login completes moments later. Add a Sandstorm-only reactive
autorun that sends the user from 'atSignIn' back to 'home' as soon as
Meteor.userId() is set, so the grain lands on the All Boards page.
Thanks to xet7.
Link the fix that rewrites ROOT_URL to the grain's real URL so DDP, dynamic
imports and the Sandstorm auto-login stop failing cross-origin.
Thanks to xet7.
WeKan loaded but stayed on "Must be logged in", and the console showed
"Cross-Origin Request Blocked ... http://127.0.0.1:4000/__meteor__/dynamic-import/fetch".
The launcher sets a fixed ROOT_URL (http://127.0.0.1:4000, the internal bridge
target), but Sandstorm serves each grain at a per-session host (ui-<hash>.<host>)
via sandstorm-http-bridge, so the client sent its DDP connection and dynamic-import
fetches to 127.0.0.1:4000 - cross-origin and unreachable from the browser - and the
header-based login handshake (a DDP method call) never completed. Add a
WebApp.addRuntimeConfigHook that rewrites ROOT_URL to the grain's real base URL
(X-Sandstorm-Base-Path) per request, and re-asserts the SANDSTORM flag, so the
client talks to the same origin it loaded from. DDP, dynamic imports and the
Sandstorm auto-login now work.
Thanks to xet7.
Link the fix that sets process.env.SANDSTORM=1 in the launcher so the
Sandstorm header-based auto-login runs and pages stop showing "Must be logged in".
Thanks to xet7.
WeKan loads in the grain but every page showed "Must be logged in". The
wekan-accounts-sandstorm client only starts the automatic X-Sandstorm-* header
login when __meteor_runtime_config__.SANDSTORM is set, and the package only sets
that when process.env.SANDSTORM is present - which nothing did (start.js set
MONGO_URL/ROOT_URL/PORT/WRITABLE_PATH but not SANDSTORM, and the pkgdef env didn't
either). The launcher now sets process.env.SANDSTORM = '1' before loading the WeKan
bundle, so the package enables the runtime flag and the client auto-logs-in the
Sandstorm user from the X-Sandstorm-* headers. (App code detects Sandstorm via a
separate Meteor.settings.public.sandstorm flag from the pkgdef METEOR_SETTINGS,
which already worked.)
Thanks to xet7.
Link the change that stops auto-creating a board on a new grain and maps the
grain's Sandstorm permissions to the user's global WeKan role.
Thanks to xet7.
WeKan on Sandstorm is multi-board now, so a new grain/user no longer gets a
hard-coded 'sandstorm'/libreboard board auto-created - the user creates their own
boards from the All Boards page. The Users.after.insert hook no longer inserts that
board + Default swimlane. updateUserPermissions previously added the user as a
member of that single board (which would now crash, since the board no longer
exists); it now maps the grain's Sandstorm permissions to the user's GLOBAL WeKan
role instead - 'configure' (grain owner) becomes a WeKan admin, everyone else is a
regular user who can create and manage their own boards. Dropped the now-unused
Boards/Swimlanes imports.
Thanks to xet7.
WeKan on Sandstorm originally opened a single hard-coded board
(/b/sandstorm/libreboard) and redirected "/" to it. It now supports many boards and
that libreboard is no longer the right destination, so redirecting to it is wrong.
Remove the WebApp.handlers.get("/") redirect entirely: "/" now falls through to
WeKan's normal serving, whose client "home" route (config/router.js) renders the
All Boards list - the right landing page for a multi-board grain. This also removes
the server-side redirect that browsers rejected as a Corrupted Content Error
(FlowRouter.path does not resolve on the server + Content-Length mismatch).
Thanks to xet7.
Link the fix that builds the Sandstorm board redirect path directly and sends a
body with a matching Content-Length, so the grain's "/" stops failing with a
browser Corrupted Content Error.
Thanks to xet7.
The grain's "/" served a broken 301: Location was ".../:6080board" because
FlowRouter.path() does not resolve on the server in Meteor 3.x (it returned the
bare route name "board"), and the response advertised Content-Length: 90 while
sending an empty body, which the browser rejected as a "Corrupted Content Error"
(NS_ERROR_NET_CORRUPTED_CONTENT). Build the board path directly (/b/:id/:slug, the
'board' route) and send a real HTML body (meta-refresh + link) with a matching
Content-Length, so the redirect to the hard-coded Sandstorm board works. Together
with the Accept-Encoding strip (keeps Content-Length valid) and the modern bridge.
Thanks to xet7.
Link the fix that bundles a modern sandstorm-http-bridge (from the Sandstorm
install) so the grain stops serving Corrupted Content on WeKan's "/" redirect.
Thanks to xet7.
The grain boots, but the page failed with a browser "Corrupted Content Error"
(NS_ERROR_NET_CORRUPTED_CONTENT) on WeKan's "/" redirect (0 bytes, ~8.5s, then
failed). The meteor-spk 0.6.0 base bundles an ancient (~2016) sandstorm-http-bridge
that mangles responses - it always advertises Accept-Encoding: gzip to the app and
mishandles redirect/encoding. build-deps.sh now overwrites the bundled
/sandstorm-http-bridge with the modern one from a Sandstorm install
(/opt/sandstorm/latest/bin/sandstorm-http-bridge; override with SANDSTORM_HTTP_BRIDGE).
Sandstorm is amd64-only so one binary covers it. The sandstorm.yml workflow now
installs Sandstorm before assembling the deps so the bridge is available on the CI
runner. Complements the app-side Accept-Encoding strip.
Thanks to xet7.
Link the fix that strips Accept-Encoding in the Sandstorm grain so Meteor serves
uncompressed responses and the browser stops showing a Corrupted Content Error.
Thanks to xet7.
The grain now boots, but the page failed to load with a browser "Corrupted Content
Error" (NS_ERROR_NET_CORRUPTED_CONTENT). sandstorm-http-bridge advertises
"Accept-Encoding: gzip" to the app regardless of what the browser actually sent, so
Meteor served gzip/brotli-encoded responses the browser could not decode. Strip
Accept-Encoding in a WebApp.rawHandlers middleware (which runs before Meteor's
static/boilerplate serving) so responses go out uncompressed; bandwidth is a
non-issue behind the local bridge.
Thanks to xet7.
Link the fix that makes the services.sandstorm.id unique index use boolean
options so FerretDB accepts it and the Sandstorm grain boots past index creation.
Thanks to xet7.
wekan-accounts-sandstorm created the unique index on services.sandstorm.id with
{unique: 1, sparse: 1}. Real MongoDB accepts the truthy 1, but FerretDB (used by
the Sandstorm .spk) is strict and rejects it with "The field 'unique' has value
unique: 1, which is not convertible to bool", crashing the grain at boot during
index creation. Use real booleans (unique: true, sparse: true).
Thanks to xet7.
Link the fix that imports the Users/Boards/Swimlanes/Activities collections and
drops the removed-HTTP-package monkey patch, so the Sandstorm grain boots past
the capnp guard.
Thanks to xet7.
Once the capnp load was made non-fatal, the grain reached the rest of sandstorm.js
and hit two latent Meteor-2.x-isms the Meteor 3.x migration missed (this file only
runs on Sandstorm, so it was not exercised): (1) it referenced the Users, Boards,
Swimlanes and Activities collections as implicit globals, but those are now ES
module default exports, so `Users.after.insert` threw "Users is not defined" at
boot; and (2) it monkey-patched `HTTP.methods` from the meteor/http package, which
was removed in the Meteor 3.x migration, so `HTTP` was undefined. Import the
collections (and Accounts) explicitly, and remove the obsolete HTTP.methods patch
(WeKan's REST API no longer uses it - it uses WebApp/JsonRoutes with header auth).
Thanks to xet7.
Link the release-workflow change that builds amd64/arm64 natively on GitHub and
moves the exotic arches to a non-blocking per-arch Launchpad matrix, so the
release no longer hangs hours on riscv64.
Thanks to xet7.
The single snap job ran `snapcraft remote-build` for all 5 platforms on Launchpad
and blocked until the slowest resolved, so the release hung ~3.5h on riscv64's
Launchpad queue even though amd64+arm64 finished in minutes. Split it in two:
snap-native builds amd64 (ubuntu-24.04) and arm64 (ubuntu-24.04-arm) NATIVELY on
GitHub runners via snapcore/action-build; snap-launchpad builds s390x/ppc64el/
riscv64 on Launchpad in a NON-BLOCKING (continue-on-error), per-arch matrix
(remote-build --build-for <arch>) so a slow or failed exotic arch never delays the
release or the other arches. Each arch publishes to the Snap Store
(candidate,beta,edge) and attaches to the GitHub Release the moment it finishes.
All 5 arches still ship.
Thanks to xet7.
Link the fix that stops capnp.node's Node 24 ABI mismatch from crash-looping
the Sandstorm grain; the grain now boots and core WeKan works via the
sandstorm-http-bridge headers.
Thanks to xet7.
WeKan on Sandstorm bundles Node 24, but capnp.node (node-capnp) is built for an
older Node ABI (NODE_MODULE_VERSION 83 = Node 14), so `Npm.require('capnp')` in
sandstorm.js failed with ERR_DLOPEN_FAILED and crash-looped the whole grain on
boot. Load Cap'n Proto lazily in a try/catch and degrade gracefully: the grain
boots and core WeKan works, because login and user identity come from the
sandstorm-http-bridge X-Sandstorm-* HTTP headers (wekan-accounts-sandstorm) and
need no Cap'n Proto. Only the two capnp-only features are skipped when the addon
cannot load - the Powerbox identity-claim method and the Sandstorm activity
notifications - and they log a clear warning. These can be restored by rebuilding
node-capnp for Node 24, or reimplemented over the bridge's HTTP/JSON API (see the
Sandstorm CHANGELOG: use Cap'n Proto APIs without Cap'n Proto).
Thanks to xet7.
Link the fix that points FerretDB's --state-dir to writable /var so the
Sandstorm grain starts instead of crash-looping on a read-only /state.json.
Thanks to xet7.
FerretDB persists a state.json (version/UUID) via its state provider even
when telemetry is disabled, and its --state-dir defaults to "." — which in a
Sandstorm grain is "/", read-only. So FerretDB failed with "Failed to create
state provider: failed to persist state: open /state.json: read-only file
system", exited (code 1), and the grain crash-looped. sandstorm-src/start.js
now creates /var/ferretdb and passes --state-dir=/var/ferretdb (plus the
FERRETDB_STATE_DIR env) in startFerret(), covering both the migration and the
steady-state FerretDB launches.
Thanks to xet7.
List the glibc-loader grain crash-loop fix, the Sandstorm build-workflow
userns/ref fix, and the Meteor unit tests __dirname server-boot fix in the
Upcoming release section, each linking to its commit.
Thanks to xet7.
server/lib/tests/dependencies.openapi.tests.js is an ES module (top-level
import) that referenced the bare __dirname global. Under Node 24 / Meteor 3.5
the compiler injects "const __dirname = fileURLToPath(import.meta.url)" for
ESM files that use __dirname, which collides with the __dirname the CommonJS
module wrapper already provides, so the whole server bundle failed to boot
with "Identifier '__dirname' has already been declared" and the "Meteor unit
tests" CI job died before any test ran. Drop the __dirname seed
(process.env.PWD already reaches the repo root under `meteor test`, and the
suite skips gracefully otherwise).
Thanks to xet7.
Ubuntu 24.04 defaults kernel.apparmor_restrict_unprivileged_userns=1, which
blocks the unprivileged user namespaces the Sandstorm install and the spk
supervisor rely on, so sandstorm.yml now relaxes it on the runner. Also added
a "ref" workflow_dispatch input and check out that ref instead of a hardcoded
main, so a fix branch can be built and tested before it is merged to main.
Thanks to xet7.
The .spk bundled the host's new glibc libc.so.6 (Ubuntu 24.04, glibc 2.39)
but kept the old glibc 2.31 ld-linux from the meteor-spk 0.6.0 base, so node
failed at startup with "libc.so.6: undefined symbol: _dl_audit_symbind_alt,
version GLIBC_PRIVATE" (HTTP-BRIDGE exit 127) and the grain crash-looped.
sandstorm-src/build-deps.sh now also copies the host's ld-linux-x86-64.so.2
into the deps so the loader and libc are the same glibc, and adds a [verify]
gate that fails the build if the bundled libc and loader glibc versions
differ or the bundled node cannot run under them - turning a silent grain
crash-loop into a loud build failure.
Thanks to xet7.
Dependabot #6451 bumped lib-storage to ~3.1085.0, whose peer requires
client-s3 ^3.1085.0, but client-s3 was left at ^3.1071.0 — breaking
meteor npm install / npm ci with an ERESOLVE peer conflict.
- Drop the ~300 MB of modern MongoDB Database Tools (wekan/mongo-tools) from the
Sandstorm build: they are unused there (Sandstorm backs up/restores grains
itself; the MongoDB 3 -> FerretDB migration uses the legacy migratemongo CLIs +
the .mjs importer). They stay in the .zip bundle / Docker / Snap, which use them.
- Set PUPPETEER_SKIP_DOWNLOAD=1 for the Meteor build (puppeteer is a test-only
devDependency; its ~150 MB Chromium must never end up in the .spk).
- Pack step prints the .spk size and warns when it exceeds 100 MB.
meteor-spk pack crashed with 'open(/home/runner/.sandstorm-keyring): No such file
or directory' because the keyring restore step wrote the decoded SANDSTORM_KEYRING
secret to ~/.sandstorm/sandstorm-keyring, but spk reads the app private key from
~/.sandstorm-keyring (a file directly in $HOME). Write it to the correct path, and
fail early with an actionable message when the secret is missing (the .spk cannot
be signed without it) instead of the cryptic later crash.
The meteor-spk 0.6.0 base ships some runtime libs in meteor-spk.deps/lib as
DANGLING symlinks (e.g. libstdc++.so.6 -> a lib that no longer exists). When step
[3/7] refreshed them with the host's newer libs, 'cp -fL' refused with 'not writing
through dangling symlink' and failed the Sandstorm build. Add --remove-destination
so cp deletes the existing destination (dangling symlink included) before copying
the host's real library. Verified: plain 'cp -fL' reproduces the error; with
--remove-destination it succeeds and writes a real file.
In the swimlanes view, boardBody.js disabled the .js-swimlanes sortable — which
also carries moving a card from one swimlane to another — with !isBoardAdmin(),
though its own comment said it should be disabled only for non-members. So a normal
board member could move a card within a swimlane but not between swimlanes (and
could not reorder swimlanes). Gate it on !Utils.canModifyCard() instead (the client
write-access predicate: board member, not comment-only/worker/read-only), matching
the server's allowIsBoardMemberWithWriteAccess.
The install page (../w/wekan.fi/install/index.html) links to Node.js downloads for
each snap/bundle arch: the OFFICIAL nodejs.org build (amd64/arm64/s390x/ppc64le)
and the UNOFFICIAL unofficial-builds.nodejs.org build (riscv64, which nodejs.org
has no binary for). release-website.sh only updated the displayed Node.js version
number, and version.sh's local website block did not touch Node.js at all, so those
download URLs went stale (404) after a Node.js bump.
Both now rewrite the version in the nodejs.org/dist/vX.Y.Z and
unofficial-builds.nodejs.org/download/release/vX.Y.Z paths and the
node-vX.Y.Z-linux-<arch> filename to the current Dockerfile NODE_VERSION.
FerretDB/ and sandstorm/ were already ignored; add /mongo-tools/ and /mongosh/ so
that temporarily cloning those wekan repos under this repo for editing never risks
committing them (they are separate git repos).
core24 allows the candidate channel (core26 does not), so the automated
release-all.yml snap job publishes to candidate + beta + edge. The stable channel
is not published by the workflow — it is done manually later once proven. Updated
the workflow, snapcraft.yaml header, CHANGELOG and CPU-platforms.md.
The default snapcraft.yaml is base: core24 (grade: stable) so it CAN be published
to the Snap stable channel, but that is done manually once it is proven stable
enough (core26 cannot go to stable). Revert the automated release-all.yml snap job
to publish to edge + beta channels (was candidate + edge). Update the workflow
header, snapcraft.yaml header, CHANGELOG and CPU-platforms.md to match.
Bundle launchers (releases/ferretdb/start-wekan.sh/.bat): run the bundle's own
per-platform binaries — FerretDB (./ferretdb[.exe]) in the background and WeKan
(./main.js on the bundled ./node[.exe]) in the foreground — inside a restart loop,
so if WeKan exits the whole stack restarts. Ctrl-C / closing the window stops both.
Snap wekan part: the wekan-<arch>.zip bundle is now the single source of every
binary. Handle all snap arches (amd64, arm64, s390x, ppc64el->ppc64le, riscv64);
use the bundle's OWN arch-correct Node.js (fixes riscv64, which nodejs.org has no
build for) instead of re-downloading from nodejs.org; move the bundle's per-arch
MongoDB Database Tools into $SNAP/bin; keep the bundle's ferretdb. Drop the
separate mongotools part (the tools already ship in the bundle), so nothing is
downloaded twice.
Previously the per-arch MongoDB Database Tools were only in the Snap and the
Windows bundle. Now every build embeds them from the wekan/mongo-tools fork's
newest release (per-arch <tool>-<arch>):
- Linux .zip bundles (amd64/arm64/s390x/ppc64le/riscv64) download their arch's 8
tools; the win64 and macOS jobs drop the inherited Linux tools and add their own
(win64 .exe, mac-arm64). The Docker image inherits them from the Linux bundle.
- Sandstorm build-deps.sh adds the amd64 tools (separate from the legacy MongoDB
3.2 migratemongo CLIs used for the one-time migration).
All from wekan/mongo-tools, none from mongodb.com.
Databases / MongoDB clients:
- Remove the mongosh binary everywhere (snap + bundles). All scripted DB access
(readiness ping, replica-set initiate/status, v8.43 schema migration) now runs
through the new snap-src/bin/db-eval (bundled Node.js 24 + the mongodb driver).
Ports wekan-control, mongodb-control, migration-control, start-wekan.sh/.bat and
migrate-schema-v843.js -> .mjs off mongosh. The legacy MongoDB 3.2 mongo shell
(migratemongo, amd64) stays for migration-time reads only.
- MongoDB Database Tools now come from the wekan/mongo-tools fork (pure Go, every
arch) instead of mongodb.com, in snapcraft and the Windows bundle. version.sh /
test-download-urls.sh no longer probe mongodb.com for mongosh/tools. The MongoDB 7
server (mongod) is still fetched from MongoDB (amd64/arm64 only).
- FerretDB v1 downloaded per-arch (ferretdb-<arch>) from wekan/FerretDB, no
ferretdb.zip: release-all.yml bundle jobs, docker-compose.yml, sandstorm build.
Snap:
- Default snapcraft.yaml is now the core24 grade:stable build (core26 variant kept
as snapcraft-core26.yaml); release publishes to candidate + edge.
- Add s390x, ppc64el, riscv64 platforms as FerretDB-only (mongod not built there);
new installs default to FerretDB v1 (snap/hooks/install already guards existing
MongoDB data), DDP_TRANSPORT=sockjs. Fix Caddy ppc64el->ppc64le mapping.
Docs: add docs/Platforms/FOSS/Snap/CPU-platforms.md; update CHANGELOG and the
Sandstorm migration doc.
Add a "Build from source & start (up -d --build)" action to the Docker
menus in rebuild-wekan.sh and rebuild-wekan.bat. It builds the wekan-app
image from the local Dockerfile, tags it as the image the chosen compose
file references (ghcr.io/wekan/wekan:latest), and starts that freshly
built container instead of a possibly-stale prebuilt image pulled from
the registry - useful when a source change (e.g. the FerretDB
Version-page detection) is not in the pulled image yet.
Remove the obsolete top-level "version:" attribute from all docker
compose files, which Docker Compose v2 warns about and ignores:
docker-compose.yml, docker-compose-ferretdb-v2-postgresql.yml,
docker-compose-multitenancy.yml, .devcontainer/docker-compose.yml, and
docs/Databases/ToroDB-PostgreSQL/docker-compose.yml.
Thanks to xet7 !
Rename docker-compose-ferretdb-v1-sqlite.yml -> docker-compose.yml (the
new default) and the old MongoDB docker-compose.yml ->
docker-compose-mongodb-v7.yml, so "docker compose up -d" uses the light,
self-contained FerretDB v1 + embedded SQLite from
https://github.com/wekan/FerretDB by default.
Update rebuild-wekan.sh and rebuild-wekan.bat Docker menus to list
FerretDB v1 SQLite first (default) and point at the new filenames.
Update the compose files' own header comments (self-identification and
cross-references), note the new default at the top of docker-compose.yml,
and update the Docker docs (main Docker.md gets a compose-file/database
map; FerretDB2-PostgreSQL.md points at the v2 postgresql compose file).
Thanks to xet7 !
The Dev server options killed only the app port, but "meteor run" also
starts an rspack dev server on 8080 that can outlive the meteor parent.
A leftover one made restarting a dev server crash with
"Error: listen EADDRINUSE ... :8080". The kill now frees both the app
port and the rspack port 8080 (Meteor.devServerPort || 8080), matching
the rspack watcher by its devServerPort env.
Port detection now checks the listening socket directly (ss/lsof with a
bash /dev/tcp fallback that needs no external tools; netstat on .bat)
instead of an HTTP probe, so it also catches a server that is still
building and not yet serving. Fixes a hang where lsof did reverse-DNS
without -nP.
Add a new "Dev server -> Kill all dev servers" menu option that frees
every dev/test port the scripts use at once: dev app 3000 + Mongo 3001,
Mocha test server 3100 + Mongo 3101, Sandstorm standalone dev 4000 +
Mongo 4001, and rspack 8080. It kills meteor, the rspack watcher and
Meteor's bundled --replSet meteor Mongos, never a production/system
Mongo. Both scripts escalate to SIGKILL if a port does not free up.
Update CHANGELOG and Build-from-source.md docs.
Thanks to xet7 !
Every "Dev server" menu option now stops any Meteor dev server already
listening on its port before starting a fresh one, so re-running a dev
option no longer fails because the port is taken. .sh adds a reusable
kill_meteor_on_port helper called by all six dev options; .bat funnels
them through :runlog, which calls a new :kill_meteor_on_port (netstat +
taskkill). Both wait for the port to free up and escalate to SIGKILL.
Also update the build-from-source docs (README.md, Build-from-source.md,
Build-and-Create-Pull-Request.md, Emoji.md, and the two Sandstorm
developer docs) to the new two-level menu (Setup -> Install dependencies,
Setup -> Build WeKan, Dev server -> localhost:3000), fix a stale
dev-server port (localhost:4000 -> 3000), and fix the README anchor link
to the renamed heading. Add a CHANGELOG entry.
Thanks to xet7 !
Use the Finnish term jyva for Sandstorm grain in the sandstorm-migration
strings: Sandstorm-jyvassa, jyvan hakemistoihin, kayttavat jyvassa, jyvan
levytilan.
Translate the 12 sandstorm-migration-* strings in fi.i18n.json, matching the
existing WeKan Finnish terminology (siirto, Liitetiedostot, Profiilikuvat,
tiedostojärjestelmä, Poista, Tallennustila). The proper noun Sandstorm and the
literal paths/DB names are kept as-is.
Remove the en.i18n.json key sandstorm-migration whose value was the bare
proper noun 'Sandstorm' (the https://sandstorm.org project name), and hardcode
'Sandstorm' in the Admin Panel / Attachments tab label and panel title instead.
The other sandstorm-migration-* keys are real translatable strings and stay.
Replace the long flat menu with a short top-level menu (Setup / Dev server /
Tests / Docker / Tools / Quit); each opens a small submenu with 0) Back, so
only a few items show at once and labels are shorter (category gives context).
Docker becomes a two-stage submenu: pick backend, then Start (up -d) / Follow
logs (logs -f) / Stop (down) -- removing 12 near-identical flat entries.
All action handlers are unchanged; only the front-end dispatch is regrouped:
.sh keeps every case handler and reaches them via a choose() 'short|full' map
(dispatch wrapped in 'for _once in 1'); .bat routes category submenus to the
existing :labels. Verified: .sh bash -n clean + all 23 menu labels map to a
handler; .bat has no orphan gotos.
Expands the docker-compose menu so each backend (MongoDB docker-compose.yml,
FerretDB v1 SQLite, FerretDB v2 PostgreSQL, MongoDB Multitenancy) has three
grouped entries -- Start (up -d), Follow logs (logs -f) and Stop (down) --
instead of just Start. The .sh uses a generalized wekan_docker helper that
auto-detects 'docker compose' vs legacy 'docker-compose'.
New menu entries run 'docker compose -f <file> up -d' for each backend:
MongoDB (docker-compose.yml), FerretDB v1 SQLite, FerretDB v2 PostgreSQL,
and MongoDB Multitenancy. Each prints follow-logs + stop commands. The .sh
auto-detects 'docker compose' vs legacy 'docker-compose'.
The MONGODB_LOG_PATH/TOPOLOGY/SERVER_SELECTION/CONNECTION=debug vars were
temporary mongodb-driver diagnostics that got committed by accident; they
flood wekan-app logs with topology JSON. Remove them from the example compose.
Driver debug logs showed a 2nd, TLS-enabled Mongo monitor connection
retrying every ~0.5s against the plaintext FerretDB port; FerretDB logged
each rejection at WARN. Harmless (WeKan uses the real plaintext connection)
but noisy. Start FerretDB with --log-level=error everywhere it is launched
(Docker entrypoint, snap ferretdb-control, release start-wekan.sh, the
v1-sqlite compose example).
Also remove the dead, unused MongoDB Driver System (server/mongodb-driver-startup.js
and models/lib/{meteorMongoIntegration,mongodbConnectionManager,mongodbDriverManager}.js)
- an abandoned MongoDB 3.0-8.0 auto-detect/driver-select experiment whose
driver packages were never installed. WeKan uses the mongodb-7 driver via Meteor.
gitignore the local FerretDB/ reference clone.
The caddy part fetched Caddy from the Cloudsmith apt repo
(curl dl.cloudsmith.io | gpg --dearmor), which fails on Launchpad remote
builders (restricted network via a fetch proxy): gpg got no key
('no valid OpenPGP data found') and override-build failed with code 2 on
both arches. Download the official prebuilt vanilla Caddy static binary from
GitHub releases instead (per-arch, latest stable + pinned fallback). WeKan
uses only built-in Caddy directives, so no apt repo, gpg, or xcaddy needed.
Applied to both snapcraft.yaml and snapcraft-core24.yaml.
The wekan/FerretDB v1 fork's buildInfo reports a top-level ferretdbVersion
string (e.g. v1.24.2-60-gb5523566) + ferretdbFeatures, and its commit in
gitVersion -- not a ferretdb sub-document. Detection only checked
buildInfo.ferretdb, so the Version page showed Database type: MongoDB and
hid the FerretDB rows. Handle both shapes: top-level ferretdbVersion/
ferretdbFeatures and the ferretdb sub-document. Also confirm in the Sandstorm
doc that FerretDB writes <dir>/wekan.sqlite (+ -shm/-wal).
- start.js: chain niscu (2.x) -> MongoDB 3.0 -> FerretDB; keep niscud + old
bundled driver for the niscu->3.0 stage. Migration from old versions is
permanent (not dropped).
- build-deps.sh (new): assemble a modern meteor-spk.deps on top of upstream
meteor-spk 0.6.0 from dl.sandstorm.io (already has mongod 3.0 + niscud);
swap in Node 24, add FerretDB + Mongo 3.x CLIs + launcher/importer, keep
niscud. Extra binaries from GitHub releases. Nothing needed from projects.7z.
- sandstorm.yml: replace the dead releases.wekan.team/projects.7z download with
build-deps.sh.
- sandstorm-pkgdef.capnp: WRITABLE_PATH -> /var/files.
- docs: keep-niscu + build-source corrections; migration support is permanent.
CJS meteor-spk.deps launcher: on grain start, if old MongoDB 3.0 data exists and
migration is not yet done, start mongod 3.0 (wait for ready), start FerretDB v1
(SQLite), run migrate-mongo3-to-ferretdb (text -> FerretDB, GridFS attachments/
avatars -> /var/files), mark done (old data kept); then run WeKan (Node 24) on
FerretDB steady-state. Paths resolve from __dirname (grain mount root). Update
the design doc to point at the canonical file and mark the in-app panel done.
projects/ (unarchived meteor-spk fork binaries) and sandstorm/ (clone of
sandstorm-io/sandstorm) are large, machine-specific working copies used only
when building the Sandstorm .spk; never commit them.
When isSandstorm, show a new Sandstorm section in Admin Panel / Attachments:
one-time MongoDB 3 -> FerretDB migration status, disk space used by the raw
MongoDB 3 files / FerretDB SQLite / attachments / avatars in the grain, and a
guarded button to delete the redundant raw MongoDB files (only after a
confirmed-successful migration, behind a confirm) to free grain disk space.
- server/methods/sandstormMigration.js: admin-gated sandstormMigrationStatus
+ sandstormDeleteRawMongo (isSandstorm-gated, env-overridable grain paths).
- client Attachments: new Sandstorm tab (jade + js), shown only when isSandstorm.
- imports/i18n/data/en.i18n.json: sandstorm-* UI strings.
- migrate-mongo3-to-ferretdb.mjs: optional STATUS_FILE with the final migration
state, which the panel reads (shared by snap + the Sandstorm spk).
Existing Sandstorm docs live under docs/Platforms/FOSS/Sandstorm/; move the
new Meteor3/Migration.md there (was mistakenly at docs/Platforms/Sandstorm/),
fix its relative links (one level deeper) and the CHANGELOG path.
Add docs/Platforms/Sandstorm/Meteor3/Migration.md: how to build a modern
Sandstorm .spk (Node 24, FerretDB v1 SQLite) migrating an existing grain's
MongoDB 3.0 data on first launch, reusing the snap's migrate-mongo3-to-ferretdb
logic. Includes seccomp compatibility analysis, rewritten start.js, and a new
isSandstorm-only Admin Panel / Attachments / Sandstorm section design.
wekan.help backup/migration instructions hardcoded
/var/snap/wekan/common/files, which is wrong for a parallel snap install
(e.g. wekan_customer -> /var/snap/wekan_customer/common). Print
$SNAP_COMMON/files instead, which snapd sets per instance. Display-only;
all functional snap paths already derive from $SNAP_COMMON/$SNAP_DATA.
The .loadLanguage suite stubbed addResourceBundle on the shared
TAPi18n.i18n singleton and asserted the call count. loadLanguage()
reads this.i18n late and each test re-init()s the singleton, so
cross-test state could leave the stub on a different i18next instance
than the bundle was registered on, making the count read 0 and the run
intermittently report 'expected addResourceBundle to be called once'.
Assert on observable i18next state (hasResourceBundle/getResourceBundle
under the normalised toI18nCode) instead, and stop a leaked
Tracker.autorun in the .getLanguage reactive test.
registerCron() used the synchronous BackupSettings.findOne/upsert, which
Meteor 3 forbids on the server, so cron init threw and scheduled backups
never registered. Use findOneAsync/upsertAsync, make registerCron async,
and await it in all callers. Add tests/backupCron.test.cjs (positive +
negative + source guard) to the test:unit:node suite.
The Meteor/rspack build failed on server/methods/backup.js:
- archiver@8 is now pure ESM with no default export and no archiver('zip', …)
factory — it exports classes. Use `import { ZipArchive } from 'archiver'` and
`new ZipArchive({ zlib: { level: 6 } })` (the streaming API — directory/append/
finalize/pipe/on — is inherited from the Archiver core class).
- The S3 streaming upload requires @aws-sdk/lib-storage, which was not a
dependency (only @aws-sdk/client-s3 was), so rspack failed with
"Can't resolve '@aws-sdk/lib-storage'". Add it, pinned to ~3.1073.0 to match
the installed @aws-sdk/client-s3 (3.1073.0) and avoid the newer lib-storage's
peer requirement on a newer client-s3.
Refresh the Upcoming section: re-point every commit link to the current hash
(the earlier links referenced pre-rebase hashes that are not on GitHub), and add
bullets for the newest commits — Transifex duplicate-key fix, Finnish
translations, unit + negative tests, and the Alternative-Architectures doc.
Document which CPU architectures WeKan can run on and why, the architecture
matrix (Node 24 vs MongoDB vs FerretDB v1), why armhf/armv7l/i386/loong64 are
not supported (Node dropped 32-bit; QEMU/base-image gaps for loong64), the
JavaScript-engine alternatives (Deno/Bun cover fewer arches; QuickJS/JSC/
SpiderMonkey/JVM run on 32-bit but cannot run Meteor), and the server-rewrite
options (Go recommended, QuickJS niche, Tcl/Tk a poor fit for a web app), plus
hardware notes (ODroid-U3, Raspberry Pi OS 32-bit, ReactOS).
Extract the pure, security- and correctness-critical logic of the recent features
into Meteor-free models/lib/* modules (so production and tests share one
implementation) and add plain-Node tests with positive AND negative cases, wired
into test:unit:node:
- models/lib/mongoSelectorSafety.js hasWhere() — the windowed card publication
refuses a client selector carrying $where (server-side JS). Tests: safe
selectors pass; $where at top level / in $and / deep in arrays / in $elemMatch
is rejected. (was inline in server/publications/cardsWindow.js)
- models/lib/cardsLoading.js resolveCardsLoadingMode / parseCardsLoadingEnv /
windowCountId — CARDS_LOADING maps to 'lazy' only for exactly "lazy" (garbage
never enables the experimental mode); a falsy swimlane id collapses to one
count-doc id (listBody uses undefined, listHeader uses ''). (used by
server/cards-loading.js, server/models/settings.js, client/lib/lazyCards.js)
- models/lib/base64Chunk.js encodeAligned/encodeFinal — streaming an attachment
into the JSON export as base64 in any chunk sizes reconstructs exactly the
whole-file base64; aligned pieces never carry padding. (used by
Exporter.buildStream)
- models/lib/backupPaths.js filesRootFrom/scheduleText — WRITABLE_PATH -> files
root (no double /files suffix, Windows-safe) and the synced-cron schedule text
(daily/weekly/monthly + defaults, unknown frequency falls back to daily). (used
by server/methods/backup.js)
41 new assertions across 4 files, all passing; whole test:unit:node suite green.
en.i18n.json had two "database-migration" and two "database-migration-description"
keys, so the Transifex push failed with "Duplicate string key". The later
(block-2) copies — "Database Migration" / "Updating database structure..." — were
unused (only the Admin Panel / Attachments migration UI references these keys, and
it needs the MongoDB<->FerretDB wording in the earlier copy). Removed the unused
duplicates; JSON now parses with unique keys.
In lazy mode minimongo holds only the loaded window, so the list card-counter
badge and the WIP-limit checks (reachedWipLimit / exceededWipLimit, the add-card
gate, and setting the WIP limit to the current count) previously reflected only
the cards loaded so far. They now use lazyListCardCount(), which subscribes to
and reads the server-side count for the SAME selector list.cards(swimlaneId) uses
(listCardsSelector + the board Filter) — so the count is exactly the accurate
value list.cards(swimlaneId).length would report if every card were loaded. The
template's whole-list count uses (cards.length) are routed through a new
cardsCountWhole helper the same way. Default 'all' mode falls back to the loaded
length and is unchanged.
Adds the CARDS_LOADING=all|lazy knob everywhere WeKan is configured:
- docker-compose.yml and the two FerretDB compose files (v1-sqlite, v2-postgresql)
- releases/ferretdb/start-wekan.sh and start-wekan.bat (bundle launchers)
- releases/virtualbox/start-wekan.sh
- snap: added to snap-src/bin/config keys + triplet, so
"snap set wekan cards-loading=lazy" works, with an example in wekan-help.
All default to 'all' (unchanged behaviour).
Client side of CARDS_LOADING=lazy. In lazy mode each list's cardsWithLimit
subscribes to boardCardsWindow for just the cards it renders (growing with the
infinite-scroll limit) and to boardListCardCount for the total; showSpinner uses
that server count to decide whether more cards remain, since minimongo now holds
only the loaded window. Default 'all' mode is unchanged (helpers short-circuit on
isLazyCards()).
Adds Admin Panel / Features — a new admin section (route /admin-features, nav
entry, adminFeatures template) intended as the home for optional / performance /
future tier-gated capabilities. First control: "Card loading" (all | lazy), which
writes the cardsLoading Setting; it mirrors, and is overridden on startup by, the
CARDS_LOADING env var. Includes an experimental-note (counters/WIP limits and the
Calendar/Table/Gantt views reflect only loaded cards; reload boards after change)
and the i18n keys.
Adds an opt-in card-loading mode for very large boards. Default 'all' is
unchanged: the board publication still ships every card into minimongo.
When CARDS_LOADING=lazy (env) or Admin Panel / Features = lazy:
- The board publication no longer ships all cards, their comments/attachments,
or the board-level checklists/checklistItems (gated by a lazyCards() check).
- A new publish-composite 'boardCardsWindow' publishes only the cards of one
list/swimlane window (the client passes the exact selector it renders with,
which is ANDed with a server-forced { boardId, archived:false } scope and
refuses $where), plus each visible card's comments, attachments, checklists
and checklist items. As the user scrolls the client raises the limit and
re-subscribes, streaming more cards in on demand.
- A 'boardListCardCount' publication reactively publishes each window's total
card count into the client-only boardListCardCounts collection, so the client
knows whether more cards remain to load.
The mode is a Settings field (cardsLoading), seeded from the CARDS_LOADING env
var (authoritative on startup when set) and mirrored onto
Meteor.settings.public.cardsLoading for the publications to read; an
after.update hook keeps it in sync when an admin changes it.
The client HTML export cloned the live DOM and built the whole .zip as an
in-memory blob. Two problems on large boards: infinite scroll keeps only ~10
cards per list in the DOM, so most cards were missing from the export; and the
entire archive was buffered in browser RAM.
Before snapshotting, every list's cardlimit is now lifted so the whole board
renders (then we wait for Blaze to flush). The zip is written with JSZip's
generateInternalStream piped straight to the chosen file via the File System
Access API, chunk by chunk with backpressure, so the archive is never held
whole in memory; browsers without the API fall back to the previous blob
download.
The board export routes buffered the entire board in memory before sending:
JSON export built one object with every card, comment, activity, checklist and
base64 attachment; CSV called that same build(); Excel additionally loaded data
it never renders (activities/checklists/subtasks/rules) and did O(n^2)
result.cards.find() lookups. On big boards this peaked at gigabytes and could
exceed V8's max string length.
Now:
- Exporter.buildStream(res) writes the JSON document straight to the response a
document at a time from raw Mongo cursors, encoding each attachment file to
base64 in 3-byte-aligned chunks. Same _format/keys, so import round-trips.
- Exporter.buildCsvStream(res) keeps only the small lookup tables in memory and
streams cards from a cursor, writing one CSV/TSV row at a time.
- ExporterExcel uses the exceljs streaming WorkbookWriter, committing each row
to the response, drops the unused collections, and resolves parent/comment
card titles via an id->title map instead of scanning all cards.
Peak memory stays flat regardless of board size.
Admin Panel / Attachments / Backup no longer loads whole files or the whole
zip into memory. The backup zip is written with archiver, streaming each
attachment/avatar straight from disk (archive.directory) and each text
collection a document at a time from a Mongo cursor as NDJSON, piped directly
to the destination (filesystem or S3/Azure/GCS streaming upload) with no temp
file. Restore reads the zip with unzipper, piping each file entry to disk and
each NDJSON data entry line-by-line in 200-doc batches. A board with thousands
of cards or a 5 GB attachment now backs up/restores with flat memory.
Sandstorm packaging is not tested well enough yet, so it should not run as part of
a full release. Remove the build-sandstorm job from release-all.yml, and add a
separate, manually-triggered sandstorm.yml that ONLY builds the Sandstorm .spk and
uploads it as wekan-sandstorm-YYYY_MM_DD-HH_MM_SS.spk to the newest WeKan GitHub
Release (found via `gh release list`), plus a workflow artifact — so it can be
downloaded and tested for errors without affecting releases. Same experimental
caveats (unprivileged user namespaces, SANDSTORM_KEYRING signing secret).
Thanks to xet7.
Adds a Backup section to Admin Panel / Attachments:
- Checkboxes to select Attachments, Avatars and/or Data (all text-based
collections that are not attachments/avatars).
- Storage dropdown (filesystem, S3/MinIO, Azure, GCS).
- Backup now: the .zip is STREAMED DIRECTLY to the selected storage — no temp
file, no extra disk — as backup/YYYY/MM/DD/HH_MM_SS/backup.zip containing
YYYY_MM_DD-HH_MM_SS/{attachments,avatars,data/<collection>.json}. Filesystem
pipes to the file; S3 uses @aws-sdk/lib-storage streaming Upload, Azure
uploadStream, GCS createWriteStream (cloud creds from the storage tabs).
- Scheduler (off/daily/weekly/monthly + time/day) saved and run via synced-cron.
- List backups: table with storage, datetime, path; select one and Restore with
"Add missing data only" or "Replace all data".
Server methods (admin-only): runBackup, restoreBackup, listBackups,
getBackupSchedule, saveBackupSchedule, backupStatus (polled for live progress).
The cloud upload paths and restore are not exercised end-to-end here; the whole
zip is assembled with jszip, so very large attachment sets use notable memory.
Thanks to xet7.
Adds a "Database migration" section to Admin Panel / Attachments with two buttons:
migrate text-based data (everything except attachments/avatars, which stay on the
filesystem) to FerretDB v1 (SQLite), or back to MongoDB.
WeKan is connected to one database at a time, so the new server methods open a
SECOND driver connection to the OTHER database (both MongoDB and FerretDB v1 speak
the MongoDB wire protocol) and copy the text collections from the live database
into it, upserting by _id (idempotent, re-runnable). The target URL is
WEKAN_FERRETDB_URL (default mongodb://127.0.0.1:27018/wekan) or WEKAN_MONGODB_URL
(default mongodb://127.0.0.1:27019/wekan); both must be running. Progress is polled
via migrateTextDatabaseStatus and shown live. After it finishes, point MONGO_URL at
the other database and restart (on Snap: snap set wekan database=ferretdb / =mongodb).
Admin-only. Attachments/avatars are skipped (they live on the filesystem).
Thanks to xet7.
Per the design: a MongoDB 7 database works with newest WeKan as-is and is NOT
migrated; only the old WeKan 6.09 / MongoDB 3.2 data is migrated to FerretDB v1.
- migration-control now: if mongod 7 can open the existing $SNAP_COMMON data it is
MongoDB 6/7 -> no migration (mark done, keep MongoDB); otherwise it is MongoDB
3.x -> migrate to FerretDB. The dump/restore-into-mongod-7 hop is removed.
- New importer migrate-mongo3-to-ferretdb.mjs reads MongoDB 3.2 with the legacy
mongo CLI (mongoexport — the modern Node driver can't talk to 3.2) and inserts
into a running FerretDB with the Node driver: text data streamed directly, and
CollectionFS/Meteor-Files GridFS attachments+avatars reassembled per-file from
exported chunks straight to files/attachments and files/avatars (no duplicate
copy, no mongodump/mongorestore, no intermediate MongoDB 7). Progress at ROOT_URL.
- FerretDB SQLite now lives at <files>/db, next to attachments/avatars (the
"files/<name>" layout), in ferretdb-control, migration-control, the offline
start-wekan.sh/.bat, the Docker entrypoint and docker-compose-ferretdb-v1-sqlite.
The amd64 6.09/MongoDB-3.2 path is not yet tested against real 6.09 data.
Thanks to xet7.
The bundled Node MongoDB driver cannot connect to a MongoDB 3.2 server, and no
single driver version spans 3.2 and MongoDB 7 / FerretDB. So instead of aliasing
an old (EOL) Node driver into package.json, use the migratemongo CLI tools for the
amd64 6.09/3.2 case: migration-control now dumps the 'wekan' database with the old
migratemongo mongodump (MongoDB 3.2, old libraries), then loads it into a fresh
temporary mongod 7 with the snap's modern mongorestore. The existing driver-based
migrator then reads that mongod 7 exactly like the arm64 MongoDB-7 case (both
GridFS types -> filesystem, text -> FerretDB v1 SQLite). The MongoDB-7 path
(arm64 + amd64-on-newest-WeKan) connects the driver directly, unchanged.
Also fix a real bug: the standalone migrator script in $SNAP/bin could not resolve
its `mongodb`/`bson` imports; set NODE_PATH to the WeKan bundle's node_modules.
Thanks to xet7.
Per docs/Backup/Backup.md and https://github.com/wekan/migratemongo, running the
old MongoDB tools/server in the snap needs LC_ALL=C, the mongo binaries on PATH,
and their libraries on LD_LIBRARY_PATH ($SNAP/lib/<arch>-linux-gnu). The 2016
MongoDB 3.2 binaries additionally need old libraries (libssl/libcrypto.so.1.0.0,
libpng12, libexpat) that modern bases lack.
- Add a migratemongo snapcraft part (both snapcraft.yaml and snapcraft-core24.yaml)
that stages https://github.com/wekan/migratemongo at $SNAP/migratemongo (bin/ =
MongoDB 3.2 binaries, lib/x86_64-linux-gnu/ = the old libraries, avx/ = QEMU
wrappers for non-AVX CPUs), amd64 only. This also fills in the
$SNAP/migratemongo/avx path that mongodb-control / mongodb-backup /
mongodb-restore already referenced but was never bundled.
- Replace the naive fresh-download mongodb-old part (a bare 3.2 mongod with no old
libs) with this.
- migration-control now reads the amd64 6.09 MongoDB 3.2 data with
$SNAP/migratemongo/bin/mongod, LD_LIBRARY_PATH=$SNAP/migratemongo/lib/..., and
the legacy $SNAP/migratemongo/bin/mongo shell (mongosh cannot talk to 3.2). The
MongoDB 7 path (arm64 + amd64-on-newest-WeKan) still uses the snap's mongod 7 +
mongosh.
Thanks to xet7.
On first boot after upgrading an old MongoDB-based WeKan snap, mongodb-control now
hands off to a new migration-control before starting mongod:
- Detects existing MongoDB data in $SNAP_COMMON and opens it with the right
bundled mongod: mongod 7 for MongoDB 7 data (all arches, including the arm64
snaps already on newest WeKan), or a bundled old mongod 3.2 (amd64 only, new
mongodb-old part) for WeKan 6.09 / MongoDB 3.2 data.
- Starts a temporary FerretDB v1 (SQLite) and runs migrate-mongodb-to-ferretdb.mjs,
which migrates text data to FerretDB and BOTH CollectionFS GridFS and
Meteor-Files GridFS attachments+avatars to the filesystem, shows a live progress
counter at ROOT_URL, checkpoints to $SNAP_COMMON (resumable), and compacts the
old MongoDB when done.
- On success switches the snap to database=ferretdb.
Idempotent (migration-pending helper + completion marker), resumable, never
deletes the source MongoDB data, only switches on success. The migrator is bundled
into the snap (/bin). Progress dashboard title fixed to 'MongoDB -> FerretDB'.
NOT yet tested end-to-end against a real 6.09 snap; in particular the 2016 mongod
3.2 binary may need extra runtime libraries on a modern base (amd64 6.09 path).
The arm64/MongoDB-7 path uses the already-bundled mongod 7.
Thanks to xet7.
- docker-compose-ferretdb.yml -> docker-compose-ferretdb-v2-postgresql.yml
(FerretDB 2 + PostgreSQL/DocumentDB, unchanged database).
- Add docker-compose-ferretdb-v1-sqlite.yml: FerretDB v1 with the embedded SQLite
backend, no PostgreSQL/MongoDB. Its ferretdb service fetches the v1 binary for
its architecture from the newest wekan/FerretDB release
(https://github.com/wekan/FerretDB/releases), caches it on the volume, and runs
it with --handler=sqlite.
Both compose files now carry the FULL wekan service from docker-compose.yml
(every documented environment variable and feature); the ONLY differences are
database-related: the ferretdb service replaces the mongodb service, MONGO_URL
points at FerretDB, MONGO_OPLOG_URL is dropped and METEOR_REACTIVITY_ORDER is
polling (FerretDB has no MongoDB change streams / replica-set oplog).
Thanks to xet7.
When upgrading from an old WeKan snap, $SNAP_COMMON/Caddyfile may still be in
Caddy v1 format, which Caddy 2 cannot parse (so caddy would fail to start).
caddy-control now runs migrate-caddyfile-v1-to-v2.sh before 'caddy run' when
caddy is enabled. It is safe: a no-op if the file already parses as Caddy 2;
otherwise it backs up the original, converts the common v1 directives (drop the
http:// scheme, 'proxy / TARGET' -> 'reverse_proxy TARGET', drop the v1
'websocket'/'transparent' presets that Caddy 2 does by default, 'gzip' ->
'encode gzip'), validates the result with 'caddy adapt', and only keeps it if
valid — falling back to the shipped Caddy 2 template otherwise, so caddy always
starts with valid config.
Thanks to xet7.
Two additions to the MongoDB -> FerretDB / GridFS -> filesystem migrator used by
the Snap and Sandstorm migrations:
- Resumable: progress is checkpointed to $WRITABLE_PATH/migration-progress.json
(atomic write) after every collection and file phase. On restart the migrator
loads the checkpoint and SKIPS collections it already finished, so an
interrupted migration (snap refresh, Sandstorm grain restart, power loss)
continues instead of starting over. Safe because every document is upserted.
- Compact after success: once the migration is complete (fresh run, or a later
boot that finds the completion marker), it runs 'compact' on each source
MongoDB collection so WiredTiger returns the now-duplicated disk space to the
OS. Runs once (tracked by a 'compacted' flag on the marker) and is best-effort.
The existing ROOT_URL progress dashboard and disk-space checks (statfsSync) are
kept; the dashboard is restored from the checkpoint on resume.
Thanks to xet7.
Mirrors releases/release-sandstorm.sh + releases/install-sandstorm.sh: installs
Meteor, meteor-spk 0.6.0 (from the WeKan projects.7z) and a dev Sandstorm, then
'meteor-spk pack' produces wekan-<version>.spk and attaches it to the GitHub
Release. Decoupled from the release job so it never blocks the core release.
EXPERIMENTAL in CI: Sandstorm needs unprivileged user namespaces (GitHub's Ubuntu
VMs allow them), and meteor-spk signs the .spk with the app private key from the
Sandstorm keyring -> provide it as the SANDSTORM_KEYRING secret. 'spk publish' to
the app market and the scp upload stay manual, as in release-sandstorm.sh.
Thanks to xet7.
Each wekan-<version>-<arch>.zip is now fully offline: its bundle/ directory
contains the WeKan server, a Node.js binary for that platform, a FerretDB v1
(SQLite) binary, and a start-wekan.sh (start-wekan.bat on Windows) that by
default runs WeKan on the bundled Node against the bundled FerretDB SQLite,
storing data and attachments/avatars on the filesystem under WRITABLE_PATH
(like docs/Platforms/Propietary/Windows/Offline.md). Override with WEKAN_DB /
MONGO_URL to use an external database.
- build-amd64/arm64/mac copy the runner's own Node 24 (matching arch); the
emulated ppc64le/s390x/riscv64 builds copy the target-arch Node they already
download; win64 bundles node.exe. Each overwrites the base bundle's node.
- start-wekan.sh supersedes start-wekan-ferretdb.sh (removed).
- Docker and snap have their own Node + entrypoint/wekan-control, so they strip
the redundant bundled node + launchers (keeping the ferretdb binary), saving
~80 MB per image/snap.
Thanks to xet7.
The main snapcraft.yaml uses base core26, which needs build-base devel + grade
devel until core26 is released, so it can only go to Snap Beta/Edge. This adds a
base core24 variant (a released base, grade stable) that builds the SAME newest
WeKan (Meteor 3.5, Node.js 24, FerretDB v1, MongoDB 7, Caddy 2), so the Stable
channel can be updated from the old 6.09 snap. Only base/build-base/grade differ
from snapcraft.yaml; migration wiring is added separately.
Thanks to xet7.
FerretDB is now built and released separately in the wekan/FerretDB repo (its
build.sh cross-compiles every platform into ferretdb.zip and attaches it to a
release there). The WeKan release workflow no longer sets up Go or compiles
FerretDB: build-ferretdb just downloads the newest ferretdb.zip from
https://github.com/wekan/FerretDB/releases/latest and republishes it as a
workflow artifact, and every WeKan build embeds its per-arch binary from that.
ferretdb.zip is no longer attached to the WeKan releases, since it already lives
on the wekan/FerretDB releases.
Thanks to xet7.
Under a sub-path deployment (ROOT_URL like https://host/wekan, typically behind a
reverse proxy that strips the prefix), language selection and other lazy-loaded
features failed with:
Error serving static file ENOENT ... /programs/server/build-chunks/build-chunks/<id>.js
rspack's client runtime builds each chunk URL as __webpack_public_path__ + chunkName,
and chunkName already includes the 'build-chunks/' prefix (u = e => 'build-chunks/'+e+...).
The default public path is '/', so at the site root chunks resolve correctly to
/build-chunks/<chunk>. But client/00-startup.js set the sub-path public path to
_rootPath + '/build-chunks/', so rspack appended a second 'build-chunks/', yielding
/wekan/build-chunks/build-chunks/<chunk> — which 404s. Set the public path to
_rootPath + '/' and let rspack add 'build-chunks/' itself.
Thanks to xet7.
Adds a build-ferretdb job that cross-compiles FerretDB v1 (wekan/FerretDB, pure-Go
SQLite backend, CGO off, no QEMU) for every platform Go + modernc.org/sqlite
support — not only the arches Node.js runs on — and packs them into ferretdb.zip:
ferretdb/<arch>/ferretdb-<arch> (Linux/macOS/BSD, executable)
ferretdb/<arch>/ferretdb-<arch>.exe (Windows only)
ferretdb/README.md (links to https://github.com/wekan/FerretDB)
Targets that do not compile on a given platform are skipped, so the zip contains
exactly what builds. ferretdb.zip is attached to the GitHub Release, and every
WeKan build (amd64, arm64, ppc64le, s390x, riscv64, win64, mac-arm64; and via the
bundle the docker image and snap) now extracts its FerretDB binary from that same
ferretdb.zip, so there is one source of truth. Windows/macOS bundles now include
FerretDB too (previously stripped), tolerant of an arch that FerretDB can't build.
Thanks to xet7.
getStatistics now reports, in Admin Panel / Version:
- Database type: MongoDB or FerretDB (detected from buildInfo.ferretdb).
- MongoDB-compatible version and the server git commit (buildInfo.gitVersion).
- FerretDB version and commit, when the server is FerretDB.
- Storage engine: WiredTiger for MongoDB, SQLite for FerretDB.
- Reactivity mode currently in use: changeStreams / oplog / polling (from
Meteor's oplog handle; FerretDB has no oplog so it shows polling).
Thanks to xet7.
Adds a 'database' snap setting (mongodb|ferretdb). A new ferretdb service runs
FerretDB v1 (SQLite) on the same port MongoDB would use; only one database runs
at a time. The configure hook flips the two services when the setting changes,
mongodb-control disables itself when ferretdb is selected, and wekan-control
drops MONGO_OPLOG_URL for FerretDB (which has no replica-set oplog, so WeKan
uses polling) and waits on a plain ping instead of rs.status().
The FerretDB binary ships inside the WeKan bundle the wekan part already
downloads, so no extra build is needed. New installs default to FerretDB on all
platforms via the install hook (fresh installs only; upgrades keep MongoDB, and
a pre-existing MongoDB data dir is detected and kept). Switch with
'snap set wekan database=mongodb'.
mongosh collects anonymized usage analytics by default and the snap invokes it
several times; disable it (writable HOME + disableTelemetry) so nothing phones
home. mongod itself has no phone-home telemetry (Free Monitoring is opt-in).
Thanks to xet7.
The extra-arch bundle build ran node:24-slim under QEMU, but the official
node:24 image publishes no linux/s390x manifest (only amd64/arm64/ppc64le),
so the s390x leg failed with 'no matching manifest for linux/s390x'. Build
the emulated native-module rebuild on an ubuntu:26.04 base (which publishes
every arch) and install the Node.js binary from nodejs.org instead; riscv64
uses unofficial-builds.nodejs.org (nodejs.org ships no riscv64).
MongoDB Community only ships amd64/arm64 server binaries, so on ppc64le,
s390x and riscv64 WeKan now bundles FerretDB v1 (the wekan/FerretDB fork with
its embedded pure-Go SQLite backend, MongoDB wire protocol). The FerretDB
binary is cross-compiled once for all five arches (CGO off, static, no QEMU)
and embedded in every .zip next to main.js, so amd64/arm64 users can opt in
too via WEKAN_DB=ferretdb. The Docker image now covers all five arches and
auto-starts FerretDB on the MongoDB-less ones. FerretDB telemetry is disabled
and locked (--telemetry=disable, plus DO_NOT_TRACK). armv7l is still excluded:
no Node.js 24 build exists for it anywhere.
Thanks to xet7.
The swimlanes CRUD e2e test (23-rest-api-more.e2e.js:209) regressed on all
browsers. Root cause: on the server ReactiveCache.getSwimlanes is async, so
board.swimlanes() returns a Promise in the REST handler. The #3624 change read
board.swimlanes().map(s => s.sort); .map on a Promise throws, the insert never
ran, the error was swallowed by the handler's catch (returned as 200 with no
_id), and the test read .title off a null swimlane.
The earlier "move the require to a top-level import" commit was not the real
cause (the same module.exports import pattern works server-side, e.g.
ruleDeletePermission in rulesButton.js). The actual fix is to await
board.swimlanes() before mapping. This also means API-created swimlanes now get
a real max(existing sort)+1 sort — previously the un-awaited `.length` yielded
undefined, so they were stored with no sort at all, which is the #3624 symptom.
Verified: the swimlane test passed in every kept local run through
2026-07-09_02-38-07 and failed starting 09-52-25 (right after the #3624 change),
confirming the regression window; the tests/swimlaneSort.test.cjs unit test
still passes.
Two e2e tests failed across Chromium/Firefox/WebKit after this release's changes:
- 23-rest-api-more.e2e.js:209 (swimlanes: create, get, edit, delete): the
#3624 change referenced models/lib/swimlaneSort via a function-scoped
require('/models/lib/swimlaneSort'); the new module was not reliably bundled/
resolved that way, so POST /api/boards/:id/swimlanes threw, was caught, and
returned an error object with no _id — the test then read title off a null
swimlane. Import nextSwimlaneSort at the module top level, matching every
other import in server/models/swimlanes.js, so it is statically bundled.
- 02-cards-open-view.e2e.js:93 (editing the card title does not break the card):
#4236 intentionally made plain Enter insert a newline in the card title
(consistent with the description), with Ctrl/Cmd+Enter saving. The CardPage
page object still saved with plain Enter, so the title never persisted and the
read timed out. Save with Control+Enter (sends ctrlKey on every platform,
which the save handler accepts).
Server-side Mocha, import regression, and Node E2E jobs already passed; this
makes the Playwright jobs green too.
In an RTL language (e.g. Arabic) the board root is dir="rtl". Both the minicard
title (a dir="auto" .viewer) and the add-card composer textarea are dir="auto"
but had no bidirectional isolation, so they shared the surrounding bidi context.
Typing a strong RTL character into one list's composer re-resolved that shared
context and visibly reflowed the displayed minicard titles of the other lists
(no underlying data change — it reverted on refresh).
Each minicard title and the composer textarea now use `unicode-bidi: isolate`,
making them self-contained bidirectional runs that cannot perturb one another.
The isolation is locked in (positive + negative) by tests/minicardBidiIsolation.test.cjs;
full browser RTL behavior is covered by tests/playwright/specs/18-rtl-layout.e2e.js.
Thanks to xet7.
List bodies used overflow-y:auto, so on platforms/browsers with overlay
scrollbars (macOS, iOS, Android, Firefox) the scrollbar auto-hid when idle and
there was no persistent affordance that a list is scrollable.
The list body now shows a scrollbar across all engines: overflow-y:scroll to
always reserve and show the track, ::-webkit-scrollbar width + thumb/track for
Chrome/Safari/Edge and mobile WebKit/Blink, scrollbar-width + scrollbar-color
for Firefox/Gecko (desktop and Android), and scrollbar-gutter:stable so content
does not shift. The cross-browser rules come from a Meteor-free builder
models/lib/scrollbarCss.js and are applied in client/components/lists/list.css;
both the builder contract and the applied CSS are unit tested (positive +
negative, including that no hide values sneak back in) in
tests/scrollbarCss.test.cjs.
Thanks to xet7.
When a card was copied — including generating a card from a template — each
subtask was inserted as a bare card document. The parent card's checklists were
copied, but the subtasks' checklists (and their items) were never copied, so
the new card's subtasks came out empty.
Card.copy() now copies each subtask's checklists (via Checklist.copy, which also
copies the checklist items) onto the newly inserted subtask. The subtask copy
document is built by a Meteor-free helper models/lib/subtaskCopy.js
(buildCopiedSubtaskFields — re-homes the subtask under the new parent and onto
the destination board; subtaskCopyChildKinds declares 'checklists' must be
reproduced), unit tested (positive + negative) in tests/subtaskCopy.test.cjs.
Thanks to ramses345 and xet7.
POST /api/boards/:boardId/swimlanes set the new swimlane's sort to
board.swimlanes().length (a count). When the existing swimlanes' sort values
were not a contiguous 0..n-1 run (after deletions/reordering, or swimlanes
created top-first with decreasing sorts), the count collided with or preceded
existing sorts and the new swimlane appeared FIRST instead of last.
The endpoint now computes the sort with nextSwimlaneSort(): max(existing sort)+1
for a reliable append (0 on an empty board), and honors an optional explicit
`sort` in the request body (the enhancement the reporter asked for). The pure
logic lives in models/lib/swimlaneSort.js, unit tested (positive + negative) in
tests/swimlaneSort.test.cjs.
Thanks to tamasberesoebb and xet7.
The activity feed rendered "edited comment undefined" / "deleted comment
undefined" for comment edits and deletions. The template passed the comment's
ID into the "%s" of activity-editComment / activity-deleteComment: on older
activities the id was absent (literally "undefined"), and a deleted comment's
CardComment document is already removed so it cannot be looked up live either.
The edit and delete activities now store the comment text (commentText), and a
new Activities.commentDisplayText() helper picks the stored text, else the live
comment text (edit case), else an empty string — so the feed never renders the
word "undefined". The template shows the (sanitized) comment text. The
text-selection logic is a Meteor-free helper models/lib/commentActivity.js,
unit tested (positive + negative) in tests/commentActivity.test.cjs.
Thanks to janchuelo and xet7.
Renaming a linked card (or linked-board card) wrote the new title only to the
linked target (via getRealId()/linkedId), leaving the linking card's OWN title
field stale. Filter-by-title queries each card document's own title field, so a
linked card silently dropped out of title filters after being renamed.
Card.setTitle() now also writes the linking card's own title (in addition to the
linked target), keeping it filterable while preserving the existing mirror
behavior. The set of documents to update is a Meteor-free helper
models/lib/linkedCardTitle.js (computeTitleUpdateTargets), unit tested
(positive + negative) in tests/linkedCardTitle.test.cjs.
Thanks to Ben0it-T and xet7.
Creating a board from a template copies the template board. The copy inherited
the template's subtasksDefaultBoardId / dateSettingsDefaultBoardId verbatim.
When those pointed at the template board itself, subtasks created on the NEW
board were dropped onto the TEMPLATE board, and the subtask card linked back
across boards to the parent.
Board.copy() now repoints any subtasks/date-settings default that referenced
the source board to the new copy, and clears the paired list id so it self-heals
to a list on the new board. Defaults that deliberately point at another (shared)
board are left untouched. The remap logic is a Meteor-free helper
models/lib/boardCopyDefaults.js, unit tested (positive + negative) in
tests/boardCopyDefaults.test.cjs.
Thanks to Xilef11 and xet7.
Security: with "Self Registration" and "Forgot Password" disabled in the Admin
Panel, the Register (.at-signup-link) and Forgot Password (.at-pwd-link) links
were hidden only by a one-shot jQuery .hide() in userFormsLayout.onRendered.
When a login failed (notably the LDAP "User not Found" path), useraccounts
re-rendered the form and recreated those link nodes without the inline
display:none, so the links reappeared and exposed registration / password-reset
flows that were meant to be off.
The disable state is now also reflected as a class on the stable <body>
ancestor (registration-disabled / forgotpwd-disabled) with matching CSS in
userForm.css. Because the class sits on <body>, the rule re-hides every copy of
the links that useraccounts recreates after a failed login, instead of relying
on a single inline style that the re-render dropped.
Thanks to Alsterdetektive1 and xet7.
#4055 reported the calendar/date-badge week number was one week too high
(Mon-Sat) and two too high (Sunday) for 2021-10-25..31 (ISO week 43). That was
the old moment-based calculation. The current native, DST-safe
dateUtils.getISOWeek() computes these correctly (verified across a DST timezone).
Adds tests/isoWeek.test.cjs pinning the exact reported dates so the off-by-one/
two cannot silently return.
Thanks to marcungeschikts and xet7.
The card title textarea submitted on plain Enter (only Shift+Enter made a new
line), while the card description textarea and the shared inlinedForm insert a
new line on plain Enter and only save on Ctrl/Cmd+Enter. So Enter could not add
a new line in the title, an inconsistent experience.
The title keydown handler now uses a shared, Meteor-free rule isSubmitKey()
(models/lib/editorSubmitKey.js): submit ONLY on Enter together with Ctrl or Cmd;
plain Enter and Shift+Enter fall through to the textarea default (a new line).
This matches the description field exactly. Unit tested (positive + negative) in
tests/editorSubmitKey.test.cjs.
Thanks to listenerri and xet7.
With LDAP_UTF8_NAMES_SLUGIFY enabled, sync.js slugified the username with
limax(text, { separator: '.' }) to transliterate UTF-8 names. limax replaces
every run of non-alphanumeric characters — including hyphens — with the
separator, so an LDAP username like "p.parta-partb" was turned into
"p.parta.partb". The generated Wekan username no longer matched and the user
could not log in.
slug() now slugifies each hyphen-separated segment on its own and rejoins
them with '-', so hyphens (and existing dots) survive while UTF-8 characters
in each segment are still transliterated. The hyphen-preserving logic is a
Meteor/limax-free helper packages/wekan-ldap/server/usernameSlug.js
(slugifyPreservingHyphens, with the transliterate function injected), unit
tested (positive + negative) in tests/ldapUsernameSlug.test.cjs.
Thanks to RowhamD and xet7.
In the board Calendar view the week-number column was numbered from Sunday
regardless of the user's "start day of week" setting: setting Monday moved
the grid (via firstDay) but the week numbers still referred to Sunday-start
weeks. FullCalendar's default weekNumberCalculation is locale-based, so it
ignored firstDay.
The calendar now passes weekNumberCalculation that computes the number with
weekNumberByFirstDay(date, firstDay) from the same firstDay used to lay out
the grid, so the number matches the displayed week. The Meteor-free week math
lives in models/lib/weekStart.js and is unit tested (positive + negative,
including a case where Monday-start and Sunday-start must differ) in
tests/weekStart.test.cjs.
Thanks to helioguardabaxo and xet7.
The "Due this week" date filter selected the wrong week (it showed next
week's cards) and ignored the user's configured start day of week.
Root cause: relativeWeek() derived its window from startOf(now(), 'week'),
but the native dateUtils.startOf() has no 'week' case, so it returned the
date unchanged. The window therefore started at "today + startDayOfWeek"
(next week) instead of the beginning of the current week, and never took the
configured start weekday into account.
Fix:
- New Meteor-free helper models/lib/weekStart.js computes startOfWeek(),
weekRange() and weekNumberByFirstDay() for an arbitrary start day of week
(0=Sunday..6=Saturday, default Monday). Unit tested (positive + negative)
in tests/weekStart.test.cjs, including a guard that "this week" must
contain today.
- client/lib/filter.js relativeWeek() now uses weekRange(now(), weekStartDay,
0|1) so "this week" and "next week" are the correct, non-overlapping
Monday..Sunday (or configured) windows.
- The this/next-week buttons now toggle per week: clicking the active one
clears it, clicking the other switches to it (the old code reset on either
state, so you could not switch directly from this week to next week).
Thanks to mimZD and xet7.
Switching directly from one board to another using the favorites bar reused
the same boardBody template instance (currentBoard went A -> B, never null),
so boardBody.onRendered never fired again and the one-shot
Utils.setBackgroundImage() call never re-ran. The previous board's inline
background:url(...) on .board-wrapper stayed on screen. Switching via the
"all boards" list worked only because it destroys and re-creates boardBody.
Two-part fix:
- boardBody.onRendered now calls Utils.setBackgroundImage() inside a reactive
this.autorun(), so it recomputes on every board switch (and background edit).
It performs no DB writes, so there is no autorun write loop.
- setBackgroundImage() now clears any stale inline background when the new
board has no image, instead of only ever setting one. The decision is a
Meteor-free helper models/lib/boardBackground.js (computeBoardBackground),
unit tested (positive + negative) in tests/boardBackground.test.cjs. Board
color keeps being applied reactively via the .board-wrapper colorClass.
Thanks to dasarne and xet7.
The rules move-card-to-top/bottom (on another board) and link-card-to-another-board
actions failed in two ways for boards the rule creator did not own:
- The action showed BLANK after creating the rule: the wizard inserted the
trigger/action/rule with three optimistic client Collection.insert() calls
that landed in minimongo limbo once the wizard subscription stopped (and the
client allow/deny rules rejected them outright for non-owner members). These
now create the rule through the server rules.createRule method, which keeps
the action's own destination boardId.
- Execution crashed with a generic Internal Server Error: the destination
swimlane fallback dereferenced ._id on a possibly-undefined swimlane titled
exactly Default, which does not exist when the destination board's default
swimlane was renamed, translated, or the board had no such swimlane.
Resolution now uses the board's real default swimlane and a Meteor-free
resolver (models/lib/ruleActionResolve.js) that returns empty string instead
of throwing. The same guard is applied to the createCard and linkCard actions.
Unit tested (positive + negative) in tests/ruleActionResolve.test.cjs.
Thanks to DarthKillian and xet7.
Translate the strings that were still in English (mostly keys added this
release: the Rules Workflow trigger/action palette, the relative-date
unit selector, the custom color-wheel label, the Activities hide toggle
and the changed-description activity), using the terminology already used
in the existing Finnish translations.
The Organization setting "Automatically add users with the domain name"
(org.orgAutoAddUsersWithDomainName) was never read at sign-up, so a user whose
email domain matched an organization was never added to it.
Add a pure helper models/lib/orgAutoAddByDomain.js (orgsToAutoAddForEmail) that
returns the ids of orgs whose configured domain exactly matches an email domain
(case-insensitive, exact — no subdomain, empty domain matches nothing), and wire
it into Accounts.onCreateUser so every non-admin sign-up path (password, LDAP,
invitation, new OIDC user) gains the matching org memberships using the same
{ orgId, orgDisplayName } shape used elsewhere, without duplicating existing
memberships. Add tests/orgAutoAddByDomain.test.cjs.
Replace the counterintuitive unlabeled material toggle switch on the card
details Activities panel with an eye / eye-slash icon toggle: open eye means
activities are shown, crossed eye means they are hidden. Clicking flips the
state, the icon reflects the current visibility, and the tooltip states the
action (Show activities / Hide activities). The same eye pattern from the
login/register password-visibility toggle is reused for consistency.
For consistency the board sidebar Activities toggle (same showActivities
state) is switched from the check / empty-square icon to the same eye /
eye-slash icon toggle.
The "Link to this card" popup Cards pull-down previously listed cards in
board sort order, making a card hard to find on boards with many cards.
Sort it alphabetically by title (case-insensitive, locale/numeric aware)
via a small pure helper sortCardsByTitle, with unit tests. Thanks to xet7.
The REST endpoint PUT /api/boards/:boardId/lists/:listId already accepted
title, color, starred and wipLimit, but the color was stored unvalidated. It
now validates the color with normalizeListColor (a named palette color OR a
custom #rrggbb hex) and rejects an unknown color with a clear 400 instead of
silently storing None or hanging. The pure field/validation logic is extracted
to a Meteor-free helper models/lib/listApiUpdate.js so it is unit testable
without a running server (tests/listApiUpdate.test.cjs).
api.py gains two commands mirroring editcard/editcardcolor:
editlist BOARDID LISTID NEWLISTTITLE and
editlistcolor BOARDID LISTID COLOR, with usage lines in the help block.
Thanks to C0rn3j and xet7.
Labels are embedded in the board document, not a separate collection, but the
Activities label() helper looked the label id up in the Cards collection and
always returned undefined. So the addedLabel/removedLabel webhook and
notification params never got a label value and the __label__ token in the
message text rendered as a bare, generic "label" with no name.
Resolve the label from the already-loaded board via getLabelById, and add a
pure labelDisplayName() helper (name -> color -> id fallback) so a nameless
label is shown by its color, matching the UI. Add a plain-Node unit test.
Card description changes did not create an activity, so no outgoing webhook
fired (unlike title/dueAt changes, whose Cards before.update hooks log an
activity). Log an a-changedDescription activity in the Cards before.update hook,
mirroring the title-change activity, so the existing Activities.after.insert
webhook hook fires. Fires on first-time set and later edits, not on no-op /
empty->empty saves. Pure descriptionChanged helper + tests, English i18n and
activity rendering.
The workflow trigger/action palette rendered hardcoded English labels
regardless of the UI language. Palette entries now carry an i18n labelKey
translated at render time via TAPi18n.__, reusing existing rule keys where
they fit and adding new r-w-* keys for workflow-only labels. Also routed
the slot clear tooltip through the existing r-remove key.
Deleting a rule ran three separate client-side Collection.remove() calls
(Rules + Triggers + Actions). Each is gated by a per-collection allow() rule
that resolves the board from that document own boardId via
Boards.findOneAsync(doc.boardId). When a trigger/action document has no
resolvable boardId (legacy rules created before boardId was denormalised, or
docs not published to the client), the board resolves to null and
allowIsBoardAdmin returns false, so Meteor rejects the mutation with 403
"Access denied" and the delete fails even for a legitimate board admin.
Route rule deletion through a new server Meteor method rules.deleteRule, which
authorizes ONCE (active board admin or site admin) and removes the rule, its
trigger and its action server-side (bypassing the brittle client allow/deny).
The permission decision is extracted into the Meteor-free helper
models/lib/ruleDeletePermission.js and covered by
tests/ruleDeletePermission.test.cjs. No permission is loosened: only board
admins and site admins may delete, matching the board-admin gate used to
create a rule.
Add a native color wheel (<input type="color">) alongside the existing fixed
named-color swatches in the color pickers for card labels, swimlanes, lists and
cards, so any #rrggbb color can be chosen. The schema color fields accept a
custom hex in addition to the named palette (via a validation that allows the
named values or a ^#[0-9a-fA-F]{6}$ hex), and normalizeListColor now passes hex
through, so existing named-color data keeps working. When a stored value is a
hex, elements apply an inline background-color instead of the card-details- /
swimlane- / list-header- / minicard- CSS class.
A new pure, Meteor-free helper models/lib/contrastColor.js computes a readable
text color from sRGB relative luminance (white on dark, black on light),
maps the named palette to hex, and validates/normalizes hex; it is applied as
an inline text color wherever a chosen color is a background behind text (label
chips, swimlane/list headers, minicard, card details header). Covered by
tests/contrastColor.test.cjs (20 assertions).
PUT /api/boards/:boardId/labels only wrote an HTTP response inside
`if (hasOwnProperty(req.body, "label"))` and read req.body.label.color/.name
unconditionally. Two consequences:
- A body without a `label` key fell through the `if` and NEVER sent a response,
so the request hung until the client timed out (the reported "timeout").
- A body where `label` was a bare string (e.g. { "label": "labelName" }, the
exact reported payload) produced name === undefined / color === undefined and
pushed a schema-invalid label via Boards.direct, returning 200 for garbage.
- The catch returned { code: 200, data: error }, masking real failures as
success (same anti-pattern already fixed for the board create/delete handlers).
The handler now returns a 404 for an unknown board, delegates input handling to
a new pure, Meteor-free helper models/lib/restLabel.js (buildBoardLabel), and
always sends a JSON response: 2xx for a well-formed create (documented contract
unchanged), 400 with a clear message for bad input, or the real error status in
the catch. buildBoardLabel accepts { label: { name, color } } (color defaulted
when absent, rejected when unknown) and, for convenience, a bare string taken as
the label name. Added tests/restLabel.test.cjs covering these cases.
Exporter.buildCsv resolved each card list/swimlane/owner/member/assignee/label/
customField by id and read a property directly on the result of Array.find(),
which is undefined when the referenced document was deleted. Large/old boards
often contain such dangling references, so the read threw "Cannot read property
title of undefined" and crashed the whole CSV export request. Extracted the
per-card row builder into a pure, null-safe helper models/lib/exporterCsvRow.js
(unit-testable without Meteor) that emits a blank cell for a missing reference
while keeping identical output for well-formed cards. Added
tests/exporterCsvRow.test.cjs.
The Calendar view queried cards with only a board+date selector via
Board.cardsInInterval()/cardsDueInBetween() and ignored the active board
Filter (member / assignee / due-date / label / custom-field), so it showed
every card in the interval regardless of the sidebar filter, unlike the
Board / Lists / Swimlanes views.
Extract the calendar selector building into a pure, Meteor-free helper
(models/lib/calendarFilter.js) that ANDs the Filter selector into the
date-interval selector via combineWithFilter, so the Filter is always applied
and can never collide with the interval selectors top-level $or. The calendar
events() callback now passes Filter._getMongoSelector() when Filter.isActive(),
and the onRendered autorun reads Filter.isActive() so events are refetched when
the filter changes. Add tests/calendarFilter.test.cjs.
Thanks to kerier and xet7.
Follow-up to #6439, which restored the drag preview but left the drop a
no-op: dragging a board on the All Boards page in "Custom (drag order)"
mode showed the dashed-border preview, but releasing it snapped the board
back without reordering.
The drop handler built the current on-screen order from
`el.classList[0]` for each `.js-board`. But the board list item is
`li.js-board(class="{{_id}} …")`, and Jade emits the literal `js-board`
class FIRST, so classList[0] is the string "js-board" for every board —
never the board _id. The ordered ids were therefore
['js-board','js-board',…]; computeReorderedSortIndex could not find the
dragged/target ids in that array, returned null, and nothing was written
to profile.boardSortIndex. The preview still worked because it is driven
by the dragover CSS class, independent of the id.
Read each board's _id from its Blaze data context (the same source
dragstart already uses via `this._id`) instead of the literal class, so
the real display order reaches the (already correct, unit-tested) reorder
helper and the drop persists. Add a regression guard in
tests/boardSortReorder.test.cjs asserting the wrong-class extraction
("js-board" repeated) yields no mapping while real ids reorder.
On old boards a swimlane can be deleted while its cards keep the now
dangling swimlaneId (an "orphaned" card). Cards with no swimlane at all
(null / '' / missing) already surface in every swimlane, but an orphaned
card matched no existing swimlane and so appeared in NO swimlane in
swimlane view, while still showing in list view (which applies no
swimlane scope) — the reported "no swimlane" symptom where some boards
show no cards in swimlane mode but work in list mode.
Mirror the existing orphaned-LIST fallback (Swimlanes.orphanedSwimlaneLists,
which surfaces orphaned lists in the first swimlane) for cards: when a
list's cards are fetched for the board's FIRST swimlane, build the
swimlane-membership clause as a single { swimlaneId: { $nin:
<otherSwimlaneIds> } } (everything not owned by another existing
swimlane: own id, null/'', missing, or orphaned). This keeps it a single
field clause with no second $or, so the #6441 board-wide label filter
still holds. Orphaned cards therefore appear once, in the first swimlane,
without a database migration.
Threaded through the pure selector helpers (swimlaneMembershipSelector /
listCardsSelector / filteredListCardsSelector) and the in-memory sibling
filterCardsByListAndSwimlane, a new List.orphanedCardsSwimlaneIds helper,
and the cards()/cardsUnfiltered()/allCards() model methods plus the
listBody cardsWithLimit render helper. Covered by new cases in
tests/swimlaneFilter.test.cjs (18 assertions pass; #6441 guards intact).
The .loadLanguage suite intermittently reported "1 failing" (the failure bouncing between the zh-CN and fr cases). Two causes: stubbing the shared TAPi18n.i18n let state leak between tests, and asserting via sinon-chai routed the matcher through chai-as-promised so it could evaluate after afterEach's sinon.restore(). Give each test a fresh i18next instance via TAPi18n.init() (mirrors the reliable .setLanguage suite) and assert with synchronous sinon.assert.* instead of sinon-chai.
Thanks to xet7.
echo "::error::SANDSTORM_KEYRING secret is not set. 'spk publish' proves ownership of the WeKan Sandstorm app with the private key from this keyring, so publishing cannot proceed without it. Add the base64 of your ~/.sandstorm-keyring file as the SANDSTORM_KEYRING repository secret (e.g. 'base64 -w0 ~/.sandstorm-keyring')."
exit 1
fi
- name:Download the newest .spk from the WeKan release and name it wekan-<VERSION>.spk
echo "::error::SANDSTORM_KEYRING secret is not set. meteor-spk pack signs the .spk with the WeKan Sandstorm app's private key, which lives in this keyring, so packing cannot proceed without it. Add the base64 of your ~/.sandstorm-keyring file as the SANDSTORM_KEYRING repository secret (e.g. 'base64 -w0 ~/.sandstorm-keyring')."
exit 1
fi
- name:Install Meteor npm dependencies
# PUPPETEER_SKIP_DOWNLOAD: puppeteer is a devDependency used only by tests,
# not by the server, so it never belongs in the packed .spk. Skipping its
# Chromium download (~150 MB) avoids any risk of it bloating the build and
echo "::warning::$SPK is $((SPK_BYTES/1024/1024)) MiB — over Cloudflare's 100 MB upload limit. Upload via a DNS-only host / SSH tunnel to Sandstorm, or trim the bundle further."
fi
ls -la "$SPK"
echo "spk=$SPK" >> "$GITHUB_OUTPUT"
- uses:actions/upload-artifact@v7
with:
name:${{ steps.build.outputs.spk }}
path:${{ steps.build.outputs.spk }}
retention-days:7
- name:Upload the .spk to the newest WeKan release
@@ -67,7 +67,7 @@ that by providing one-click installation on various platforms.
- WeKan ® is used in [most countries of the world](https://snapcraft.io/wekan).
- WeKan ® largest user has 30k users using WeKan ® in their company.
- WeKan ® has been [translated](https://app.transifex.com/wekan/) to about 105 languages.
- WeKan ® has been [translated](https://app.transifex.com/wekan/) to 154 languages.
- [Features][features]: WeKan ® has real-time user interface.
- [Platforms](https://wekan.fi/install/): WeKan ® supports many platforms.
WeKan ® is critical part of new platforms Wekan is currently being integrated to.
@@ -103,10 +103,10 @@ By working directly with WeKan ® you get the benefit of active maintenance and
## Getting Started with Development
The default branch uses Meteor 3.5-rc.2 with Node.js 24.x.
The main branch uses Meteor 3.5 with Node.js 24.x.
See [CHANGELOG.md](https://github.com/wekan/wekan/blob/main/CHANGELOG.md) for the latest runtime updates.
To contribute, [create a fork](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#2-create-fork-of-httpsgithubcomwekanwekan-at-github-web-page) and run `./rebuild-wekan.sh` (or `./rebuild-wekan.bat` on Windows) as detailed [here](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#3-select-option-1-to-install-dependencies-and-then-enter). Once you're ready, please test your code and [submit a pull request (PR)](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#7-test).
To contribute, [create a fork](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#2-create-fork-of-httpsgithubcomwekanwekan-at-github-web-page) and run `./build.sh` (or `./build.bat` on Windows) as detailed [here](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#3-install-dependencies-build-wekan-and-run-the-dev-server). Once you're ready, please test your code and [submit a pull request (PR)](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Build-and-Create-Pull-Request.md#7-test).
Please refer to the [developer documentation](https://github.com/wekan/wekan/blob/main/docs/DeveloperDocs/Developer-Documentation.md) for more information.
@@ -138,11 +138,17 @@ curl https://install.meteor.com/ | sh
### Building WeKan
The `rebuild-wekan.sh` script guides you through a three-stage process:
The `build.sh` script shows a two-level menu. The top level groups options into categories:
1.**Install dependencies (Option 1)** - Downloads all required Meteor packages and npm modules
2.**Build WeKan (Option 2)** - Compiles the application
3.**Run WeKan (Option 3)** - Starts the development server at http://localhost:4000
```
1) Setup 2) Dev server 3) Tests 4) Docker 5) Tools 6) Quit
```
You pick a category number, then the item number inside it (each submenu also has a `Back` entry). Building from source is a three-stage process:
1.**Setup -> Install dependencies** - Downloads all required Meteor packages and npm modules
2.**Setup -> Build WeKan** - Compiles the application
3.**Dev server -> localhost:3000** - Starts the development server at http://localhost:3000
# Press 1 (Setup) and Enter, then 2 (Build WeKan) and Enter
# Step 3: Run WeKan in development mode
./rebuild-wekan.sh
# Press 3 and Enter
# Step 3: Run WeKan in development mode (Dev server -> localhost:3000)
./build.sh
# Press 2 (Dev server) and Enter, then 1 (localhost:3000) and Enter
```
If a dev server is already running on that port, the **Dev server** options stop it automatically and start a fresh server on the same port.
### WSL Users
WSL users can use Snap Candidate. See [install docs](https://wekan.fi/install/).
The development server will start at http://localhost:4000. Any changes you make to the source code will automatically trigger a rebuild and refresh your browser.
The development server will start at http://localhost:3000. Any changes you make to the source code will automatically trigger a rebuild and refresh your browser.
@@ -10,8 +10,19 @@ because WeKan is NOT Big Tech. WeKan is FLOSS.
- **Report**: Click "New draft security advisory" at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
More info at [GitHub Docs about reporting privately](https://docs.github.com/en/code-security/how-tos/report-and-fix-vulnerabilities/report-privately).
- **Proof of Concept (PoC)**: If possible, include a fix or a reproduction script/code.
-**If GitHub does not work**: Please send report to **security@wekan.fi**
- **Optional Email Encryption**: An optional PGP key is available at [security-at-wekan.fi.asc](security-at-wekan.fi.asc).
-DO NOT EMAIL [security@wekan.fi](security-at-wekan.fi.asc), because:
- Email is NOT secure or private.
- Using GitHub directly verifies that:
- You are:
- Saving my time by filling all details at GitHub, so that I can easily click request CVE at GitHub
- A correct GitHub user
- Really reading this SECURITY.md
- Knowing what you are doing
- You are not:
- Someone that tries to waste my time
- Trying to impersonate as some other GitHub user
- Spammer
- Bot
### 2. WeKan Security Team:
@@ -23,30 +34,26 @@ because WeKan is NOT Big Tech. WeKan is FLOSS.
### 3. Post-Release and Public Disclosure:
- Publicity: If you publish blog posts, give talks, or write articles about the
reported vulnerabilities, please send the links to us. We will link them
to your entry in the [Hall of Fame](https://wekan.fi/hall-of-fame/) for additional context.
- Advisories reported at GitHub are listed at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
## How Should Reports Be Formatted?
```
Name: %name
Twitter: %twitter
Bug type: %bugtype
Domain: %domain
Severity: %severity
URL: %url
PoC: %poc
CVSS (optional): %cvss
CWSS (optional): %cwss
```
- DO NOT EMAIL [security@wekan.fi](security-at-wekan.fi.asc), because:
- Email is NOT secure or private.
- Using GitHub directly verifies that:
- You are:
- Saving my time by filling all details at GitHub, so that I can easily click request CVE at GitHub
- A correct GitHub user
- Really reading this SECURITY.md
- Knowing what you are doing
- You are not:
- Someone that tries to waste my time
- Trying to impersonate as some other GitHub user
- Spammer
- Bot
## Who can participate in the program
Anyone who reports a unique security issue in scope and does not disclose it to
a third party before we have patched and updated may be upon their approval
added to the WeKan Hall of Fame https://wekan.fi/hall-of-fame/
a third party before we have patched, and is able to add
"New draft security advisory" at [WeKan Security Advisories](https://github.com/wekan/wekan/security/advisories).
# Example (Issue #2674) - add member when card moved TO list, remove member when moved AWAY FROM list:
# python3 api.py addrule BOARDID 'Add on move to Doing''{"activityType":"moveCard","listName":"Doing"}''{"actionType":"addMember","username":"someuser"}'
# python3 api.py addrule BOARDID 'Remove on move from Doing''{"activityType":"moveCard","oldListName":"Doing"}''{"actionType":"removeMember","username":"someuser"}'
Loaded 100 of 1145 files, more files were not shown because too many files have changed in this diff.
Show more
Reference in new issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
github-actions[bot]
Lauri Ojansivu
dependabot[bot]
cmartin