PurgeBleed is the severe one of the
five. DELETE /api/boards/{boardId}/lists/{listId}/cards/{cardId} authorised
the caller on the board in the URL, and then fetched the card by its id ALONE.

The order is what makes it destructive. cardRemover runs BEFORE the card is
removed - it has to, so the children's before.remove hooks still find their
parent - and it removes strictly by card id: checklists, checklist items,
comments, the activity history and the whole subcard tree. So it erased those
for whatever card the bare lookup returned, which was any card in the instance,
on boards the caller cannot read, irreversibly.

The removal that follows uses a triple key, {_id, listId, boardId}, which a
foreign card never matches. The card SHELL therefore survived and the endpoint
answered 200 with the card id - so nothing in the response said that the
contents of somebody else's card had just been destroyed, and the attack is
repeatable for every card id an attacker learns.

Any authenticated user with write access to ONE board - their own is enough -
could reach every board on the instance. All deployments with WITH_API=true
are affected.

The bulk endpoint had always constrained its lookup with {_id, boardId}; the
single-card path is the sibling that was missed, the same shape as
PassBleed. It uses the constrained
lookup now, so a card outside the authorised board does not resolve, and
cardRemover is never reached.

HashBleed: GET /api/users/{userId}
and PUT /api/users/{userId} serialised the whole Meteor user document with no
projection, so every answer carried services.password.bcrypt - an
offline-crackable password hash - and services.resume.loginTokens, the hash of
every live session with the time it began.

The authorisation was never the problem: both endpoints are admin-only and stay
that way. The payload was. Walking the ids that GET /api/users returns
harvested the credential material of the whole instance, and a password hash is
an attack that continues offline long after the export.

The two sibling endpoints in the same file show what was intended: the list
projects down to _id and username, and the self view runs delete data.services before answering. Nothing in the code, the CHANGELOG or the
documentation ever said the subtree was meant to be exposed. One helper strips
services and sessionData now, and both endpoints answer through it - the PUT
as well, which returned the same unprojected document after every action.

GuestBleed is two paths that are
each defensible alone. The members and assignees ARRAYS on card create and
card update were stored exactly as given, with nothing checking that those ids
belong to the card's board. And GET /api/user/cards answered by CARD
membership, without re-checking the caller's access to the card's BOARD.

Together they are a channel: a member of a private board writes an outsider's id
onto a card, and the outsider's own my cards feed then returns that card's
title, its board, list and swimlane ids, its dates and its co-members - for as
long as the id stays on the card. Their direct read of the board stayed
Forbidden the whole time, which is what made it quiet.

The invariant already existed, documented on the merge endpoint POST .../cards/{cardId}/members/{memberId}, which has refused a non-member with 400
since #5998. It covers the array
shapes now - single create, bulk create and update - and an id that may not be
assigned is dropped rather than the request refused, so a bulk edit does not
fail over one stale id. The listing is filtered by board visibility as well,
because fixing only the write path would leave every card placed before this
release still answering.

StaleBleed: GET /api/users/{userId}/boards selected boards with a dotted 'members.userId'
match, which ignores the membership's isActive flag. Removing a board member
does not delete their entry - it sets isActive: false and isAdmin: false and
keeps it - so a removed member's own board listing went on showing that board's
id and title, indefinitely.

Reading the board itself was already refused, which bounds this to the id and
the title. The id is the part that matters, because it is what every other
endpoint in the API is addressed by, and a private board's title is often the
thing it is private about.

A dotted path cannot express this: in Mongo, 'members.userId' and
'members.isActive' may be satisfied by DIFFERENT entries of the array.
$elemMatch is what ties them to the same entry, and it is what the rest of
WeKan uses - the single builder introduced by the fix for
GHSA-gwc4-fw7p-gw58,
whose header note reads "A share entry counts only while it is active,
everywhere". This listing predates that consolidation and was never converted.

AuthorBleed: six server paths took
the actor's identity from the request body's authorId field, checking only
that such a user exists. An existence check is not an authentication check - it
confirms that the name in the envelope belongs to somebody, and says nothing
about who wrote the letter.

So a board member could record "victim created this card" and "victim deleted
this card" on any board they may write to, and the card document itself
recorded the forged userId as its creator. The six are single card create,
bulk card create, the linked-card form, single card delete, bulk card delete and
custom-field create.

WeKan had already accepted this exact class as a vulnerability and fixed it for
card comments in 8.19, and again for the card PUT handler - whose inline note
still reads "use req.userId consistently (it previously read req.body.authorId
here)". These six were missed, which makes it an incomplete fix rather than a
decision. All six read req.userId now, the session the request authenticated
as, which is the only identity the server can vouch for.

Three CRITICAL findings and most of the HIGH ones were three copies of one
package - tar 6.2.1 twice and tar 7.5.11 once - and none of them is
reachable from boot.js:

• node-gyp and @mapbox/node-pre-gyp are dependencies of Meteor's
  meteor-dev-bundle, there to COMPILE native modules during the npm install
  in programs/server. WeKan compiles nothing at run time: uWebSockets.js,
  bcrypt and argon2 all ship prebuilt .node files that node-gyp-build picks
  at require time. Their tree is 83 of the 120 packages that install leaves
  behind, and it brought tar 6.2.1 (via node-gyp and cacache),
  brace-expansion, minimatch and npm's networking stack with it.
• npm itself runs exactly once in the image, for that install. The container
  starts bash /build/wekan-entrypoint.sh, which never calls it. Shipping it
  shipped its own bundled tar 7.5.11, sigstore 4.1.0, @sigstore/verify,
  @sigstore/core, ip-address 10.1.0 and brace-expansion 5.0.4 as image
  content no code path can reach.

releases/prune-build-only-modules.mjs removes the first, and it is a
REACHABILITY walk rather than a list of 83 names - start from every dependency
of programs/server/package.json except those two, follow each package's own
dependencies, keep the closure - so it cannot go stale the next time Meteor
changes its dev-bundle. The Dockerfile deletes npm and npx in its cleanup
step; node stays, because that is what runs WeKan.

It runs in every place a bundle is made, not only in the image: the amd64 build,
the arm64 container, the three Windows legs, both macOS legs, and
install-node-for-arch.sh for the emulated arches - each one reinstalls
programs/server, so each one has the tree to remove. The pruned bundle was
booted before and after to prove nothing needs what it takes:
identical failure at the database, no missing module.

The rest of that scan was nodemailer 8.0.3 and openpgp 5.11.1
(meteor/email),
svgo 2.8.2, postcss 8.5.1 and nanoid 3.3.15 (meteor/minifier-css), qs
6.13.0, cookie 0.4.1, on-headers 1.0.2 and tmp 0.2.3 (meteor/webapp),
lodash 4.17.21 and diff 3.5.0 (ostrio:files), body-parser 1.20.3
(meteor/oauth), @babel/runtime 7.20.7 and underscore 1.13.7.

Npm.depends names an EXACT version, and meteor build copies that version
into
programs/server/npm/node_modules/meteor/<package>/node_modules. Nothing in
this
repository's package.json is consulted for it - not a dependency, not an
overrides entry - so the only place those versions can be raised is the
bundle,
after it has been built. releases/bump-bundle-npm-deps.mjs does that from the
minimums in releases/bundle-npm-security-bumps.json, installing with
--ignore-scripts so no prebuilt native module is rebuilt by a version bump,
and
replacing only copies BELOW the minimum.

A minimum stays inside the major the Meteor package was built against, and that
rule was learned rather than assumed: uuid 8.3.2 and 9.0.1 are both affected
and the lowest fixed release is 11.1.1, which moved its entry point to
dist/cjs/index.js - the bundle records dist/index.js at build time, and the
server died on boot with Cannot find module .../uuid/dist/index.js. It is in
the manifest's notFixable list with that error, beside lodash.template,
which has no fixed release at all.

One pass on the amd64 bundle reaches every architecture, because every other
bundle is that bundle with programs/server reinstalled. That reinstall is also
why every leg runs it again: meteor-dev-bundle pins underscore 1.13.7
(CVE-2026-27601) and puts it back over the bumped copy - including in the
Dockerfile, which reinstalls from the .zip.

tests/imageBuildOnlyModules.test.cjs pins that the pruner is
reachability-driven
and never touches npm/node_modules, that the image prunes AFTER the install
and
before the bundle is moved, that npm and npx are removed and node is not, and
that every leg which installs programs/server prunes afterwards.
tests/bundleNpmSecurityBumps.test.cjs pins the manifest's versions, the
--ignore-scripts install, the below-the-minimum-only replacement, and that
uuid is NOT in minimums and says why.

Not everything in that report can be fixed here, and it is worth saying which:

• The debian 13.6 target's 176 findings are ALL Fixed in: - - unfixed
  upstream, in perl-base, util-linux, ncurses, glibc and the rest of a
  base system. No upgrade closes them; only carrying fewer packages helps, which
  is what the build-dependency purge and the pebble removal already do.
• lodash.template 4.5.0 has no fixed release; it reaches the bundle through
  aldeed:simple-schema.
• nodemailer's fifth advisory needs 9.0.1, a major the Meteor email package is
  not written against; 8.0.11 fixes the other four.
• The nine build/<tool> binaries and build/ferretdb are other repositories'
  builds - wekan/mongo-tools-patches and wekan/FerretDB - and are fixed there.

The other direction of the same popup. Importing used to mean one thing: a whole
new board, from the full-width page at All Boards. A swimlane's menu now imports
a swimlane BELOW that swimlane, a list's menu imports a list after it - which is
to its RIGHT in English and to its LEFT in Arabic - and a card's menu imports a
card below it, into the board that is already open.

The RTL side of that is ONE rule and not two, which is worth saying because it
looks like a missing branch: the page carries dir, so the board's row of lists
mirrors itself and "after in sort order" is already "the other side". A
direction
branch in the placement would mirror it twice and put the list back where it
started.

Placement is a FRACTION between the target's sort and the next one's, not a
renumbering of every sibling - renumbering is what a board with ten thousand
cards cannot afford, and what two clients doing it at once get wrong. Several
imported items spread evenly through that gap, so importing a swimlane of ten
lists does not put nine of them in the same position.

The file is what the export writes, at any scope, and the SAME checkboxes decide
what comes in: a document full of comments imported with Comments unticked
brings the cards and leaves the comments. A .zip is unpacked in the browser
and
its wekan.json handed to the same method, so there is one import path rather
than two. Nothing is merged - everything created is new, because an import that
half-updated a board would be an edit nobody could undo - and a custom field is
matched by NAME, since an id from another board matches nothing here.

Importing WRITES, so unlike the exports beside it, it asks whether you may
change
the board rather than whether you may see it, and a read-only member is not
offered it at all.

In All Boards / Starred, a bookmark tile stood 8px taller than the board tile
beside it and than the grey "+ Add Board" box, and pulled its whole row up with
it.

Two of the four tiles in that grid carry border: 4px solid #fff - a bookmark
and the Template Container - to say they are not an ordinary board. The tile's
height was a 72px floor with 42px of padding added outside it, which comes to
the same 114px for a plain tile and to 122px for a bordered one, because on a
content-box element a border is added to the height rather than taken out of it.
The heights all said 72px, so nothing in the stylesheet looked wrong.

The tile now states the height it actually renders at - 114px, with the padding
and the border folded into it (box-sizing: border-box), which is what the
mobile rules in the same file already do for the same reason. Nothing moves
except the two bordered tiles, which lose the 8px they were never meant to have.
The guard compares RENDERED heights now, borders included, instead of comparing
the declared min-height of two tiles that were both content-box - which is how
this went unnoticed while a test watched it.

The last piece of #1173: "combine
all import options to same template". They were fourteen - a link per source in
a pop-over, each going to its own address - and the page each one landed on
never said which other sources existed, so "where do I import a Jira export"
was answered by a menu somewhere else, if you knew it was there.

All Boards / + Add Board / Import is now one full-width page that lists
every source it can read - Trello, Jira, CSV/TSV, Excel, Kanboard, NextCloud
Deck, OpenProject, GitHub, GitLab, Gitea, Forgejo, Asana, Zenkit, and a previous
export of this WeKan, named with the Product name this instance is branded
with rather than with a product the reader has never seen.

Under the source picker are the same what to include checkboxes every export
offers, from the same list, and on this side they say what comes IN. That works
for every source without teaching five different creators a selection each: the
parts that were not ticked are taken OUT of the parsed document before any
creator sees it, and a creator that never sees a comment cannot import one. A
section that was not ticked is EMPTIED rather than removed, because the creators
read board.comments directly and an undefined array is a crash where an empty
one is "there were none". A source's own name for a part is pruned with it -
Trello calls its comments actions - and a key this list does not know about is
left alone rather than silently dropped.

/import/:source still works, under its own route name, so every existing link,
bookmark and back button lands exactly where it did.

The round trip was half a round trip: a card imported from a swimlane, list or
card menu arrived with its checklists and comments and without its files.

A .json export carries each attachment's bytes as base64, and the importer now
writes them the way the board import always has - the server-side Meteor-Files
writeAsync, one attachment at a time. A .zip carries them as the files they
are, named attachments/<id>-<name>; the archive is unpacked in the browser and
each file is put back on the metadata row its id names, so the server sees the
same document either way and there is one import path rather than one per
container.

An attachment lands where its CARD landed - the list and swimlane it is in now,
not the ones it was exported from - and one unreadable file is warned about and
skipped rather than losing the rest of the import. A url attachment from an
older export is still fetched through the downloader that validates and pins
every hop, so FollowBleed stays
fixed on this path too.

The whole-board import on the new import page takes a .json or a .zip
the same way, through the same reader, which is the case the .zip exists for:
a board whose attachments are too large to sit inside one JSON string.

Reading an archive in the browser and sending its attachments as base64 over DDP
is fine for a card and wrong for a board: 2 GB of attachments become 2.7 GB in
one message, in the browser's memory and then in the server's.

A .zip now goes to POST /api/import/zip as the file itself, and nothing is
ever whole in memory on the way in. The request body is streamed to a temp file
as it arrives; unzipper.Open.file reads the archive's central directory, so
entries are opened on demand rather than inflated together - the same approach
the backup restore already takes; and each attachment is piped from the archive
into the attachments collection by addAttachmentFromStream, which writes it to
a temp file and hands Meteor-Files the PATH rather than a Buffer. That helper is
lifted out of the attachment-copy code that already did exactly this, so there
is one way to add an attachment from a stream rather than two.

Where the files END UP is not decided by the import: addFile fires the
collection's onAfterUpload, which validates the file and moves it to the
default storage configured in the Admin Panel, exactly as an ordinary upload
does.

The upload is capped as it ARRIVES rather than after
(WEKAN_IMPORT_ZIP_MAX_BYTES,
5 GB by default), so an oversized archive never lands, and the temp file is
removed whatever happens. An entry's name is data and never a path: only the
attachment id before the first dash is read from it, the temp file is named by
WeKan, and the path is built through the same safeEntryPath containment check
the backup restore uses - so an entry called ../../etc/cron.d/x can only ever
be an attachment with a strange name (ZipBleed).

A .json still travels as a document over DDP, which is what it is.

Three things about the page that lists the sources. The pop-over that opens it
said "Import board (Trello, Jira, WeKan export, CSV, Excel, ...)" - a list of
five of the fourteen sources, in a menu whose only job is to get to the page
that lists all of them - and now says Import board and nothing else.

Import from: and Select what to include: were rows of grey ticks that
were never anything else: a fa-check drawn once per row, the same shape
whether that row was chosen or not, so the answer to "which one did I pick" was
a shade of grey. Both are the app's own animated checkbox now
(.materialCheckBox, the one Admin Panel / Announcement uses), which grows its
green tick out of the empty square over 0.2s, so a click is visible as it
happens. The box and its label are spaced apart by the same amount ticked or
unticked - the checked box is a narrower shape shifted left, so the two margins
differ by exactly that shift - and the row itself declares no alignment of its
own, because the tick's rotation is written for the plain flow and an
align-items: center on top of it lands the tick on the first word.

The two questions sit side by side when the window has room for two 280px
columns and stack when it does not, so the second one is not below the fold on
a page whose first list is fourteen rows long. No source is chosen to begin
with, and choosing one un-chooses the last, because an import reads one file in
one format; every part is ticked to begin with, because an import that silently
left things out would be worse than one that asks.

And Import without mapping members (map later) is a primary button like the
Import it sits beside. It was the one unstyled button on the page, which
reads as disabled - and it is not a cancel, it is the same import with one
question skipped.

A board on the clearpink theme was a pink rectangle floating inside a grey
tile, while the flat-coloured board beside it filled its tile edge to edge.

Two lists decided what a tile is coloured with. boardColors.css painted
.board-list .board-color-<name> a - the LINK inside the tile, which sits
inside the tile's own 24px/18px padding and so can never reach its edges - and
boardsList.css carried a hand-copied list of seventeen flat background
colours on the tile itself, which is what made the flat themes look right. The
five colour SLIDE themes added later were never copied into that list, so their
tiles kept the default grey and only the inset link showed the slide.
clearblue was in the list, flattened to one hex, so it did not show its
slide either, and Clean Dark and Clean Light were in neither list.

There is one list now. Each theme paints .board-list li.board-color-<name>
where it paints its header bar and its Public Boards row, the copy in
boardsList.css is gone, and a tile is the whole tile at every theme.

The other half of a theme is the text on it. A tile writes its title in
#f6f6f6, which is right on the fifteen dark themes and invisible on a light
one: Apple Glass Pastel's tile is a pastel wash from #f6f7fb, so its name
and description were white on near-white and only the tile's shape said a board
was there. Both light themes now write their title, description and archive
line in their own dark ink, and darken the card-count pill and the unstarred
star that sit on the same tile - in ONE block, named as the place a third light
theme goes, because a per-theme copy is what caused the first half of this.

The Clean Light theme's top bar is #F1F1F3, and header.css paints every
icon in that bar white by id (#header-quick-access i.fa). The buttons inside a
ul li escaped that through a more specific color: inherit and took the
theme's own text colour; the house and the notification bell are in no
ul li, so they stayed white on near-white - the bell's LABEL was readable
beside a bell that was not there, which is how it was noticed.

Both are dark now, and so is everything beside them: the bar's labels were
rgba(10, 10, 20, 0.5) and its board title full black, so fixing the two icons
alone would have left the bar at three darknesses. There is ONE shade in it now.
The current entry used to be the dark one among pale ones - a difference
that no longer exists - so it is the full-black, heavier one instead. A bell
with something to report keeps its white glyph, because it is on the red circle
then and not on the bar.

The dividers between the bar's groups - the seam that separates the page's
own controls from your account - are white too, a background in the first bar
and a border in the second, so on this theme they were not there at all. They
are in ink now, at the divider's own weight rather than the text's: a hairline
as dark as the label beside it stops reading as a seam and becomes a stroke.
The starred group's outline - the box around the caret, the count and the
star - was white for the same reason, so the three sat loose on this theme; it
is the same 0.7 in ink now, which is the dark outline the phone/desktop toggle
beside it already draws for itself and why that one looked right and this one
did not.

Hovering an icon lightens it - #header-quick-access i.fa:hover goes to
#ccc - which on a dark bar reads as "brighter, so you know you are on it" and
on this one made the house fade towards the bar it sits on. On this theme it
goes the other way, to full black, which is the same message read the right way
round for a light bar.

And with Member Settings / Change color / All Boards on, a tile is the
theme's own fill rather than the accent under a flat white veil. The veil made
every tile one shade lighter than the selected row in the left menu beside it,
which reads as two colours rather than as one page. It reads
--theme-accent-fill now, not --theme-accent: the accent is ONE colour - the
solid end of a colour-slide theme - so on clearorange the tiles came out
flat beside a menu row that slid. The fill is the theme's slide where it has
one and its accent where it does not, which is what every other themed control
already reads. The popup's own All Boards button is filled from the same
variable, because the button and the tiles it turns on are one decision and
were two looks.

On the Modern theme the popup that asks all this was a single narrow column
of swatches. That theme set width: 260px on every popup's content, so any
popup that asks for width by name - Change Color, Export board, Show on Card,
Show on Minicard - was pinned to 260px whatever it had asked for. A theme
decides what a popup looks like; how wide it is belongs to the popup, and the
declaration is gone.

And on the Dark theme that popup had no title bar at all. That theme hid
every popup's header outright, and the header is not decoration: it carries the
popup's title, the back arrow into the popup it came from, and the X - so
"Change Color" was an untitled panel that could only be left with Escape or a
click outside. No other theme does that, and Dark no longer does either.

Picking Largest grew the page heading and the minicards and left the header
bar, the left menu, the lists, the swimlane header and every popup exactly as
they were - a setting that half-works, which is harder to use than one that does
nothing.

The preset was a percentage on the root element, and a root percentage only
reaches text whose size is written in a RELATIVE unit: rem is measured against
the root, em against its parent. WeKan writes most of its sizes in px, and
px is absolute - no root percentage moves it. So exactly the rem-sized parts
scaled. The base rule made it worse: html, body, input, select, textarea, button re-stated font: 14px …, so the body took the stock size straight back
off the scaled root, and everything inheriting from the body with it.

The preset is now published as a NUMBER as well
(--wekan-ui-font-scale), and every px font-size and line-height in the
client stylesheets - 433 declarations across 37 files - is written
calc(14px * var(--wekan-ui-font-scale, 1)). One preset moves the whole
interface. line-height scales with the size on purpose: 21px of type in an
18px line box is the same setting half-applied.

Nothing renders differently until a preset is chosen: the fallback in every one
of those declarations is 1, and the variable is REMOVED for Default, so an
instance where nobody touched the setting computes exactly the sizes it always
did. The base font rule is split into font-family and font-size because the
shorthand's size was the one thing the setting had to be able to move. A guard
fails on any bare px font-size or line-height added later, so a new one
cannot quietly opt out of the setting.

Colour is inherited, and it was set on <body> and the form controls, so it
only ever reached text that had no colour of its own - and WeKan gives most of
its text one: the header bar's buttons, the left menu's rows, a minicard's
title, a list header. Choosing green recoloured the page heading and the menu
and left the rest exactly as it was. It is set on every element now.

.fa is left out, because those are Font Awesome GLYPHS rather than text - a
red alert and a green tick mean something by being that colour - and the icons
that are meant to follow their label already say color: inherit, so they
follow this anyway.

A colour painted behind the text needs elements to sit on, and neither choice of
them looks good. On the boxes - which is what it did, from <body> - it painted
the whole window: the board canvas and the empty space under the lists, which is
a page background and not a text background. On the elements that actually carry
text it striped every heading, menu row and paragraph with a full-width band. A
setting nobody can make look good is worse than no setting, so it is removed
rather than tuned a third time.

The wheel and its Unset button are gone from the popup, nothing reads
profile.uiTextBgColor, and no stylesheet rule paints it. A profile that
already HAS a colour is cleaned rather than left dormant: setUiColors unsets
the field on every call, whatever it is passed - and it still accepts the
argument, so an older client cannot fail against a newer server. The schema key
stays declared for exactly one reason: a modifier touching a key SimpleSchema
does not know is rejected, which would leave those profiles the only ones that
could not be cleaned.

The text colour beside it stays.

All three places render the same picker, so the Custom color wheel was
already written for all three - it was just never reachable in two of them. It
appeared only once a named theme had been SELECTED, and a board always has a
colour whose first entry is flat, so Board Settings / Change Color always
showed it; Member Settings / Change Color and Admin Panel / Settings /
Visibility open on Default (no override) with nothing selected, so both
looked as though they had no custom colour at all.

The wheel is offered from that state too, as the flat category's single
colour - which is what a custom colour means with no theme under it - and
choosing one applies it over the first flat theme. That fallback was already in
the code that saves; it is now written into the picker's own selection as well,
because otherwise the wheel would store a theme the page did not show as chosen
and the next click would read the selection back as none.

Picking a clear theme first still gives the two wheels its colour slide
needs. One helper answers "which category's custom colours is this picker
offering", so the wheel, the preview and what gets saved cannot disagree.

There were two export menus. The board popup wrote nineteen formats of its
own under four subheadings, in two panes across the width of the window; the
swimlane, list, card and checklist popups wrote five in one
narrow column with no panes. So "the export popup" looked like two different
features depending on which menu opened it, and a format added to one was
missing from the other.

They are one template now, drawing one TABLE of formats. Each entry says what it
is - an icon, a label, and either a path to download or a class to click - and
which scopes it belongs to: BOARD_ONLY for the ones that only make sense for a
whole board (the HTML archive, the dependency graph, the CSV columns and the
exports written for Trello, Jira, Kanboard and the rest), and nothing at all for
the ones that work anywhere, because exportUrl already carries the scope - a
swimlane, a list and a card differ from a board by a query parameter, not by a
route. The board popup is now the same one-line include the other four are, with
no markup and no URL builders of its own; the nineteen helpers that built those
URLs are gone with the list that called them.

All five get the board's panel: what to include in one pane and what to
export it to in the other, side by side when the window has room and stacked
when it does not, pinned to the viewport so the header and its X are always
reachable. The layout is written against the panes' own class rather than
against one popup's name, so it cannot be true of one menu and not another.

Which scope a popup is, is asked in ONE place - and every scope is named there,
because a scope left out would be read as "a whole board" and offered a board's
formats.

The card, list, swimlane and board menus each had ONE row, and each named itself
differently: Export card, Export list / Import, Export swimlane / Import,
Export board. Two of them mentioned an import that was a section inside the
popup rather than a thing you could go to, and the card and board menus did not
mention it at all - so importing into a list was discoverable and importing into
a card was not.

Each of the four now has Export and Import, in that order. The rows are
named for what they do and not for what they act on: the menu already says
whether it is a card, a list, a swimlane or the board, so Export card inside
the card menu said "card" twice.

Both rows open the same popup - the same panes, the same table of formats, the
same what to include selection - with one difference: the second pane offers
the formats to write out, or the file to read in. The selection means the same
thing in both directions, which is why it is the pane they share.

Import writes, so it is offered only to somebody who may change the board.
That question is asked once, in one function, registered as a helper the four
menus use - and asked AGAIN inside the popup, because a row that is merely
hidden is not a permission check.

#5006, open since 2023: "A
customer has just hinted us that we are not able to search cards by its number
(#)". A card carries a number, the board shows it, people quote it to each other
in meetings and in tickets - and the one thing that could not be done with it
was
find the card again.

number:12 now does, in the global search and everywhere else that parses the
same query. It is an EQUALITY match on a number rather than a regular expression
on text, which is the whole difference between finding card 12 and finding cards
12, 120 and 312. number:abc is refused with the same "expected a number" error
limit: already gives, because a string never equals a numeric field and a
search that quietly finds nothing teaches nobody anything.

The issue's title says "number/#", and both of those forms work too: #12 and a
bare 12 search for a label called 12 AND the card numbered 12. A board calls a
card "#12" and a label can be called anything, so which of the two somebody
means cannot be read off the text - answering with both is the only reading that
never hides what they were looking for.

The two halves are joined with OR, which is what makes that safe rather than
destructive: a search that used to find a label called 2024 still finds it,
and the card numbered 2024 is ADDED to the answer instead of replacing it. An
AND would have found nothing at all in almost every case and looked like the
feature working. Only a term that is entirely digits gets the second half, so
#red is the label red exactly as before. And #12 on a board with no label
called 12 no longer reports "label not found" - the card-number half is a real
answer, and a not-found message beside the card it just found contradicts the
screen.

Two halves of the same menu.

The selection now reaches all of it. PDF, Excel, JSON and .zip took the
parts checkboxes; CSV, TSV, Kanboard and the eleven JSON dialects built their
own
addresses and could not carry them, so ticking "no comments" changed four
downloads out of nineteen. Every board export link is built by the one url
helper now, so ?fields= rides along with all of them.

What a format can DROP depends on what it has, and that is the honest part. A
CSV has no comments to leave out - what it has is columns, so the selection
lands there: unticking People removes five of them, Dates removes eight, Custom
Fields removes the trailing block. One mask filters the header and every row, so
the two cannot drift apart. A Trello, Jira or GitHub export carries a title,
a description, a due date and labels; those three parts are gated and nothing
pretends to gate what is not there.

It is a full-width panel, and its X is always reachable. It was anchored to
the button that opens it and clamped into the window using an assumed width -
and the assumption and the stylesheet disagreed by a few percent, so on a narrow
window the panel's trailing edge, with the pop-over's own X on it, ended up past
the edge of the screen: Escape or a click away were the only ways to shut it. It
is pinned to the top of the viewport now, at the 10px gutter every popup keeps,
and is calc(100vw - 20px) wide - the whole window, less that gutter on each
side - so the header, the X and both panes are always on screen.

And the menu is a menu again. Twenty-odd entries under three subheadings
were a single column you scrolled past. On a window with room it is now TWO
PANES - what to include on the left, what to export to on the right - each
filling its own width with as many columns as fit, so the whole menu is visible
at once. The panes are grid COLUMNS, which is what makes the right-to-left case
free: a mirrored page puts the first column on the right, so the selection lands
on the right and the formats on the left with no second rule to write or forget,
and the divider between them is a border-inline-start for the same reason.
Below 800px they stack, because popup.css already lays every popup out as a
full-screen sheet there, which is what a phone should get. The 1100px width is
mirrored in client/lib/popupOffset.js, which places a popup using its width:
left at the default 380 a wide menu opened near the right edge lands most of the
way off the screen.

A rule sits above each subheading, so a group's name says where the group before
it ended - one rule per heading and no stray separators, which a test counts.

Template.exportScopeBody.helpers(...) runs at module scope, and it throws when
that template is not defined YET. That does not break one popup - it stops the
module evaluating, so every template registered after it never registers either.
The visible symptom was the SIGN-IN page: a blank form and

Uncaught TypeError: can't access property "helpers", Template.exportScopeBody is
undefined
[UserAccounts] Warning no template passwordInput found!

The central lists in client/features/*.js import a component's .jade before
its .js, which is enough for a component nobody else imports. The export popup
body is imported by the sidebar, by the card details and by the import page, and
whichever of those is reached first evaluates it - long before the feature list
gets to the template. It imports its own .jade now, so the order is a fact
rather than a hope.

A guard in tests/clientBundleImports.test.cjs checks the whole rule, and found
a second component with the same fragility that had not fired yet -
migrationProgress.js, imported by boardBody.js. Fixed the same way.

It was nineteen entries in one list, each spelling out its whole family:
"Export / CSV (,)", "Export / CSV (;)", "Export / TSV", then eleven lines
beginning "Export / JSON /". The part that differed - the only part worth
reading - started two thirds of the way along every line.

A subheading names the family once and the entries under it say only what they
are: PDF, Excel and HTML, then Dependencies (JSON, SVG), CSV
((,), (;), TSV) and JSON (JSON, JSON without attachments, .zip, Kanboard,
Trello, Jira, NextCloud Deck, OpenProject, GitHub, GitLab, Gitea, Forgejo,
Asana, Zenkit). The .zip sits with the JSON it is a container for.

The parts checkboxes stay at the top, from the shared popup body: the board
passes hideFormats because it lays the formats out itself, and borrows the
selection rather than growing a second copy of it. Its links are built by the
same url helper every other menu uses, so a menu cannot send a different
selection than the one on the screen. Nothing was dropped in the regrouping, and
a test walks the whole list in order to say so.

The board's Export menu had JSON; nothing else did, and there was no .zip at
all.
Both are now offered wherever an export is - the board, a swimlane, a list, a
card and a checklist - from the same popup, with the same checkboxes deciding
what goes in.

They are the same export in two shapes, not two exports. The document is written
by models/exporter.js's streaming writer either way, so a .zip's
wekan.json
and a .json download of the same scope are the same bytes. What differs is
where the attachments are: base64 INSIDE the document for JSON - or omitted,
with
the existing "without attachments" option now offered at every menu - and beside
it under attachments/ as the files they are for the .zip.

Both halves stream. The JSON writer already wrote a document at a time from raw
cursors with backpressure; the .zip gives it a PassThrough that archiver
compresses as it fills, and pipes every attachment from the file store rather
than reading it into a Buffer. A board with a gigabyte of attachments costs a
gigabyte of disk reads and not a gigabyte of RAM - which is what makes the
.zip
the shape to use when the JSON is too large to hold as one string.

A SCOPED export is the same wekan-board-1.0.0 document with fewer rows in it,
plus the lists and swimlanes its cards refer to, so what comes out can be
imported back into somewhere. A section the popup did not tick is an EMPTY array
rather than a missing key, for the same reason. A checklist scope exports the
card that holds it, because a checklist alone has nowhere to land.

#1173 "Add Feature: Print Board
with Params" has been open since 2017, and two things were missing. There was no
CHOICE of what to print: the board's Excel and PDF exports took everything they
knew how to render and nothing else, while the card export already had a popup
with a checkbox per section. And they did not LOOK like the card export - the
board's Excel export was a spreadsheet table, one row per card and eighteen
columns, which is a data dump rather than a printed board.

Both now render a board as the board's own header followed by every card as the
CARD export's block, drawn by the card export's own code - cardBlockLines()
for the PDF, ExporterExcelCard.renderCardBlock() for the Excel one - so a card
looks the same whether it was exported alone or as part of its board, and the
two cannot drift into two layouts again. Each card starts on its own page in the
Excel export, because a printed board is read a card at a time.

The swimlane and list menus offer the same export, which is the board export
with one more parameter saying which cards are in scope. They sit beside "Copy
link" rather than below the permission checks, because exporting is reading. The
file is named for what was exported - a PDF titled with the board that holds one
list is a file nobody can place afterwards.

Rendering a card block needs the whole board in memory, and
models/server/ExporterExcel.js STREAMS on purpose - it was rewritten that way
after the in-memory version ate gigabytes on boards with thousands of cards. So
that exporter is still there and still reachable: unticking Card details
asks for it. That is a checkbox in the popup, not a silent fallback nobody can
see.

The card export's popup had a list of sections, and the server had another one,
under a comment reading "Must match ALL_FIELDS in
models/server/ExporterExcelCard.js" - which is a comment, not a mechanism. A
section added on one side and forgotten on the other is either a checkbox that
does nothing or a section nobody can turn off.

Both now import models/lib/exportFields.js, and
so do the board, swimlane and list popups, which are ONE shared body -
exportScopeBody - included with a different scope each. The selection is
remembered for the session, because somebody printing a board rarely wants a
different shape for each list of it.

The same ?fields= gates the same sections in both formats: the card export's
checkboxes used to be labelled "fields to include in Excel export" and did
nothing to the PDF, so one popup meant two things. A section a request does not
name is not rendered and, where the export is the only reason to read it, not
even fetched.

A list's title has always been edited in place: click the heading, type, save.
A card's title could only be changed by opening the card, so correcting a typo
on a board of forty cards was open, edit, close, forty times - which is what
#4990 asked about, in 2022.

The minicard's title text is now an inlinedForm, the same component the list
heading uses, with the same textarea, Save button and X. Only the TEXT opens it,
and only for somebody who may write: the complete checkbox, the linked-card
icons and the card number beside it keep doing what they did, and everything
else on the card still opens the card. A title nobody may edit still opens it
too.

The minicard sits inside the link to the card, so a click in the open editor
would have navigated away mid-rename. That default is cancelled - except on the
Save button, whose own default IS the submit, and which the browser picks over
the link around it because the innermost element with an activation behaviour is
the one that runs. An empty save is a no-op rather than a way to end up with a
card that has nothing to click.

Half of the title edits; the other half drags. With drag handles OFF a card
is dragged by its own body, so a title that is entirely an edit target leaves
nowhere on that line to take hold of - a grab that moves a few pixels is a
click, and the editor opens instead of the card moving. The edit target is the
LEADING half (left in English, right in Arabic, from one logical edge) and the
trailing half is there to drag from. With handles ON the handle is the only drag
source, so nothing has to be reserved and the whole title edits.

The opened card's title splits the same way, and its drag handle now appears
only when drag handles are on - with them off, the title bar is what moves the
window. The drag surface there is the header ROW rather than the heading: a
heading is only as wide as its own text, so on a short title "the trailing half"
was a few pixels and the empty space beside it - the obvious place to take hold
of - belonged to nothing. The heading fills the row now, and the handler steps
aside for the buttons in it, for the drag handle when there is one, and for the
half that edits.

The board's name in the first header bar had a pencil next to it. Two targets
for one job, and the smaller of the two was the one that did it.

The name itself now opens the rename popup - the SAME boardChangeTitlePopup
that the pencil opened, with the title and the description in it, so only what
you click to get there changed. It is opened with the board as its data context,
because that bar's context is the page rather than the board. Board admins only;
everybody else sees a plain title, as before.

A board whose title is EMPTY renders no text at all, and an element with no
content is zero pixels wide - so there would be nothing to aim at, and an empty
title could never be given one. The clickable title carries a minimum width and
height for exactly that.

What subtasks DO on a board - whether they are shown at all, which board and
list a new one is deposited in, and how a parent is named on a minicard - was
in Board Settings only: open the sidebar, open the board menu, find Subtasks
Settings. Somebody who wants to change it is usually looking at a subtask on an
opened card at that moment.

It is behind a hamburger at the end of the Subtasks heading on an opened
card - where the card and the minicard already keep theirs - and clicking it
opens the same popup Board Settings did. Board Settings no longer has the
entry: the settings are where subtasks are.

The heading IS the control that folds the section, so the hamburger's click has
to stop there. Without that, opening the menu would close the thing it was
opened from.

It is the SAME template in both places, with its own state, helpers and
handlers, so neither place needs code of its own and the two lists cannot
drift. That is what the move needed: a template included in two places cannot
reach its parent's helpers, because a helper is looked up on the template it is
written in.

The heading row named the columns of a ROW - Show on Card over the checkbox
and Description over the setting's name - which is what they labelled, but not
what they looked like. The rows flow into as many columns as the window fits, so
the two headings sat above the FIRST of three or four columns and read as if
they named those: Show on Card over one column of settings and Description
over another, when both columns hold the same kind of row.

The first heading also said what the popup's own title says. Show on Card opened
a popup titled Show on Card and repeated it a line below, and the same for
Show on Minicard.

Both are gone, and the two-pixel rule under them with them - one more line
across a popup that is a list of lines. A row is a checkbox and the name of a
setting, which needs no heading over it. One template serves both popups, so
both lose it together, and the sticky positioning that existed only to keep
those headings in view while the rows scrolled goes with it.

Board Settings / Card Settings is a table of twenty-four settings with two
columns - what a card shows, and what a MINICARD shows - and it lived in one
place only: the right sidebar, four clicks from the card whose fields it
decides.

It is now also the first entry of the two menus it is about. The hamburger on an
opened card offers Show on Card, the hamburger on a card on the board offers
Show on Minicard, each followed by a rule like every other group in those
menus. Both open the SAME popup with the other column hidden by a class, so
there is still one list of settings and one set of handlers: a setting added to
the table appears in all three places by itself, and none of them can drift from
the others.

Both are wide, and lay their rows out in columns. Two dozen settings in one
column is a list nobody sees the end of - "is Description on?" was somewhere
below the fold. With one of the two checkbox columns hidden each row is half as
wide as it was, so the popup is min(90vw, 900px) and the rows flow into as
many columns as fit: one on a narrow window, three or four on a wide one, with
the headings still spanning the width because they name the columns of a ROW
rather than of the grid.

The permission is the one Board Settings already used - a board admin - asked
in the menu and again where it acts. The one menu is opened from two places and
its data context is the card either way, so the opener says which hamburger it
was in client/lib/cardMenuSource.js: a
module-level reactive value, not a field on the card document, which is gone the
next time Blaze re-renders the popup with a fresh copy of it.

It was in the right sidebar under the People and Organizations tabs, which is
not where anything else about a minicard is. It is a row of the same table now,
directly under Labels, named "Labels text" with the Labels icon and the
Description Text icon in front of it - because it is about what those labels
look like on a minicard: coloured words, or coloured bars with the words left
out.

It is ticked when the text is SHOWN, which is what a board does out of the box.
The stored flag is a "hidden" one, so reading it straight through would have
left the box unticked for the default behaviour, which reads as a broken
checkbox.

It is the one PERSONAL row of a board-wide table - the user's own profile, or
this browser when nobody is logged in - so it appears in the minicard's view
and nowhere else, and it is offered to EVERYBODY. A reader who is not a board
admin gets that row alone rather than a table of checkboxes the server would
refuse.

The move found a bug. The setting was written out three times, and the
minicard's own copy only ever wrote localStorage: a logged-in user toggling it
set something nothing reads, because for a user the value is read from the
profile. One module reads and writes it now
(client/lib/minicardLabelText.js), so the
two halves cannot disagree again.

The board's LIST of custom fields - where a field is created, renamed or
deleted - was in Board Settings only, and the picker for which of those fields
are on THIS card was down among Voting, Planning Poker and Spent time. Two
halves of one subject, three groups apart.

They are one group now, under Watch and its rule: Custom Fields first,
because a field has to exist before a card can be given it, then Edit custom
fields, then a rule like every other group in that menu. A board admin's, the
same as in Board Settings.

Card Settings is gone from Board Settings. Every setting in that table is
in the menu of the thing it is about now, so a board-wide entry as well would
be a third way to one list - and the way that is furthest from what it changes.
The table itself is unchanged; the two menus include it.

Everything about custom fields is on the section that shows them. It was
spread over three places: Board Settings had the board's LIST of fields behind a
right-sidebar view, the card menu had an entry for that list and another for the
picker of which fields are on this card, and the picker had a cog that jumped
back to the sidebar - closing the menu and the card pane on the way.

One place now: the hamburger at the end of the card's own Custom Fields
heading. It opens every field the board has, ticked when it is on THIS card,
with a pencil each and, under a rule, Add custom field. Edit and Add open in
the same pop-over on top of that list, so the back arrow returns to it and the
card stays open behind; they are the board's own forms, not second copies of
them. The card menu's entry and the Board Settings row are both gone, and so is
the wrapper popup that nothing opened any more.

It was a line in the card's menu that read "Show list on minicard", or "Hide
list on minicard" once it was on - a menu entry that changes its own name is
the shape a checkbox has, drawn as a sentence. It is a checkbox now, the FIRST
row of Show on Minicard, above Received, named List title and unchecked by
default, which is what the field itself has always been.

It shows the name of the LIST the card is in on its minicard, which is worth
having where a card is read away from the column it lives in: a swimlane,
search results, My Cards. The board-wide "Show lists" row further down the same
table turns that on for EVERY card; this one is for a single card that needs it,
and either is enough for the name to show.

It belongs to the card rather than to the board, so it is drawn only in the
minicard's own view - Board Settings has no card to act on - and only for
somebody who may change that card, which is the permission the menu entry had.
The card is passed into the popup and re-read from the collection when it is
toggled: a minicard's menu is opened from the board, where there is no "current
card" to fall back on.

On the minicard itself the name sits on its own line under the badges. It was
landing BESIDE them: the badge row is float: inline-start, so the line after
it shared its row and read as one more badge rather than as the line it is.

Two popups of the same menu answered one question. Change Background Image
asked for a URL; Board backgrounds listed the images uploaded to this board
and carried the upload button. So the popup that reads as the place to set a
background had half of the ways to set one, and the other half was behind a
different entry.

The upload is under the URL field now - a picture from the web and a picture
from this machine, read together. Board backgrounds keeps what it is named for:
the images already there, to set active, download or delete. The uploader moved
as its own template, once, rather than being copied.

In the same popup, Unset was five blank lines and a rule below the Save
it belongs beside. They are one row, Save first, sharing the width. Unset is
type="button": inside that form a button with no type is a SUBMIT button, so
beside Save it would have saved the URL it is meant to clear.

The two sections at the top of the right sidebar could not be folded at all.
The People / Organizations / Teams / Domains tabs with their avatars, and every
label of the board, were always open and pushed everything under them down the
panel.

Both have a caret in front of their heading now, and the heading is the button

• the same control an opened card's sections use, and the same one Activities
  got below them. Folding Members hides the tabs and the avatars in them;
  folding Labels hides the labels and the + that creates one. Enter and Space
  do what a click does.

The choice is the reader's and lasts the session, not the board's: neither
decides anything on the server, so folding them for yourself must not fold them
for everybody. Activities is the exception and stays as it is - its caret
writes board.showActivities, which also decides what the publication sends.

A caret leads the group, at its leading edge - left of the lock in a
left-to-right page, right of it in Arabic, because its direction comes from the
same rule every other caret uses. Folded, the seven controls after it are gone

• Private, Muted, Sort Cards, Filter, Search, Show
  dependencies and Multi-Selection - and the bar is the logo, the board's
  name and the caret.

The buttons a board's own Rules put in that bar are NOT folded with them:
somebody added those to this board on purpose, so the standard controls fold
around them. It is named by the words the app already has - Collapse and
Uncollapse - so no key was added to 147 language files to say them again, and
it answers Enter and Space like the button it says it is.

All three folds share one store, one helper and one class
(client/lib/foldState.js): a caret in the header
and a caret in the sidebar pointing different ways in one language is the bug
that avoids.

The heading read "Activities" and beside it sat an eye and the words "Show
activities" - one setting with two controls and its own name said twice. It is a
caret in front of the heading now, and the heading is the button: click it and
the activities appear under it, click it again and they are gone. That is the
same control every collapsible section of an opened card has, from the same
function (client/lib/sectionCaret.js), so the
caret cannot point one way on a card and another in the sidebar of the same
language - it points down when open, and toward the text when closed, which is
right in English and left in Arabic. It carries role="button" and a tabindex,
so Enter and Space do what a click does.

v10.91's release run failed in four jobs, and three of them - s390x,
ppc64el and riscv64 - had done all the work: each snap BUILT on
Launchpad and each was published to the Snap Store. What failed was attaching it
to the GitHub Release:

HTTP 404: Not Found (https://uploads.github.com/repos/wekan/wekan/releases/370103352/assets?label=&name=wekan_10.91_s390x.snap)

The step collected the file with two patterns - wekan_${VERSION}_<arch>*.snap
and *_<arch>.snap - and a snap called wekan_10.91_s390x.snap matches BOTH,
so the same path was passed to gh release upload --clobber twice. Asked to
attach one name twice, it deletes the asset it has just uploaded and then 404s
on it. The two other places in the same job that build this list were already
deduplicated; this one was missed.

It is deduplicated now, and the attach is confirmed from the other side the way
the native snap job already did it: read the release's assets back and fail if
this snap is not among them. An upload that reports success and leaves nothing
behind is the failure nobody notices until somebody's download 404s - and here
every job that lost an architecture had already said the snap was built and
published.

The fourth failure, armhf, is not this: snapcraft died with
SSLEOFError while downloading the build log from Launchpad, on all three
attempts, and produced no snap. That one is Launchpad's side of the wire.

v10.92's release job failed before running a line of its script, and with it
every job that needs the release - snap, docker, AppImage, the Windows and
macOS bundles - so nothing published at all:

  ##[error]An error occurred trying to start process '/usr/bin/bash' with
  working directory '/home/runner/work/wekan/wekan'. Argument list too long

Nothing in the step was wrong. The notes are the whole newest CHANGELOG
section - prepare measured them at 172,458 characters - and they reached
the step as env: CHANGELOG:. Linux caps a SINGLE argv/envp string at
MAX_ARG_STRLEN, 128 KiB, so execve refused to start the shell. The amd64
and arm64 bundles had already built and verified; only the publishing died.

The environment was itself the fix for the PREVIOUS failure. Interpolated
inline as ${{ }}, the notes become part of the shell SOURCE, so a backtick in
any code span runs as a command: that is how v10.59 published nothing and
printed Incorrect: command not found. One shape is unsafe and the other does
not scale, and this release was the first big enough to find the second wall.

So the notes stop being a shell value at all. releases/release-notes.sh prints
the CHANGELOG section for a version, reading the file itself and taking its
arguments from the environment inside a QUOTED heredoc, and each job appends its
stdout to release-notes.md. Only file PATHS are passed around, which has no
size limit and leaves the text as data that no shell ever parses.

prepare keeps the validation - a missing section is still cheap to fix there -
but no longer publishes the text as a job output, because an output nobody can
safely consume is a trap for the next person to find. The release job and the
notes-rewrite job check out ref: main, the same ref prepare read.

The guard test is rewritten around the new shape: no changelog job output, no
CHANGELOG in an env:, no interpolation into a script, and the extraction
script is what all three consumers run. It passed throughout this failure,
because it only knew about the injection.

"We upgraded to 10.91 ... Gateway timeout appears" -
#6595, from the same reporter as
#6592, whose fix shipped in 10.91.
It could not reach them: that fix is the SNAP's, and this is a container.

WeKan does not open its web port until the database answers, and in a container
nothing else was listening while it waited - so a reverse proxy in front
returned a gateway timeout, and that is the same symptom for two completely
different faults: WeKan is broken, or the database has not come up yet.

The entrypoint now asks whether the database answers (one ping, with the
driver already in the bundle), and while it does not it serves the same bridge
page the recovery case uses, saying WeKan is waiting for its database and
where to look. What is bounded is the PAGE, not the wait: a database can take
minutes to come up after an update, and giving up on it would be worse than
waiting - so when the window ends the page stops, WeKan starts, and WeKan keeps
waiting exactly as it did before. WEKAN_DB_WAIT_PAGE=false turns it off.

Reported by email against 10.91: "Still slow on loading cards. Test server with
me as only user." One user is the part that says what it is NOT - with nobody
else on the server there is no contention, no queue and no lock, so the time is
going into the queries themselves.

It was. cards, activities, cardComments, checklists and
checklistItems had no index at all - everything a board draws and everything
an opened card pulls in. "The cards of this list", "the comments of this card",
"the newest activities of this board" each walked the whole collection. That is
invisible on a demo board and expensive on a real one, and worse on FerretDB,
whose SQLite backend has to walk the same documents.

The activities publication even explains that it keeps its selector flat "so
both push down to FerretDB v1 (SQLite)'s index instead of forcing a
full-collection scan" - and there was no index for it to push down to.

Each new index matches a selector the app really makes WITH the sort it really
uses, so it serves both the filter and the order: a filter-only index still
leaves an in-memory sort of everything it matched, which on a board with a year
of history is the slow half. They are created through the same idempotent
ensureIndex every other index here uses, so a restart does not rebuild them
and a backend that refuses one logs it instead of stopping the server.

Moving from MongoDB CollectionFS to File-System stopped on some attachments
with FileNotFound: file 66336fc372e64200010f4832 was not found, and the
reporter had it exactly: it is the identical files.

A CollectionFS filerecord points at its binary by copies.<coll>.key, the id of
a file in the cfs_gridfs.<coll> bucket, and TWO filerecords can carry the SAME
key - the same file attached twice, or a board copied with its attachments. The
migration deleted the binary as soon as it had moved the FIRST of them, so the
second read a file that was no longer there. The binary now goes only when no
other filerecord still names it, and when the question cannot be asked the
binary stays: a file left behind can be removed later, an attachment deleted out
from under another record cannot be brought back.

A binary that really is missing - metadata restored without the chunks - is no
longer a MongoDB stack trace naming a GridFS id. It names the attachment, says
where it was looked for, and counts as SKIPPED rather than failed, because there
was nothing to move. The Admin Panel's summary line shows how many were skipped
and how many failed, so a run that leaves attachments behind cannot look like a
run that moved everything.

An instance whose MongoDB data was written by a MongoDB older than any mongod
the snap carries printed this at every start, before the site came up:
BOTH databases have been written to since the migration and then [autopick] reading both databases to see which one holds the work ....

mongodb_has_data answers "are the files there", not "can anything here open
them", and on that instance those are different answers - mongod 7, 5.0 and
4.2 each refused the files in turn. So the comparison ran on a copy that cannot
be served, and it is not a cheap question: it starts a mongod that cannot open
the data, and then a SECOND FerretDB against the SQLite directory the running
one already holds.

migration-control has already tried every reader in the snap and left
.mongodb-data-too-old behind when none could open the files. With that marker
present the MongoDB copy is no longer a candidate, and WeKan serves the FerretDB
that has the data. Nothing is deleted and the marker stays: it is true, and it
is right again on a snap that can read those files.

snap run wekan.database-compare answered MongoDB: <unreadable> and
FerretDB: <unreadable> on a live instance whose wekan.sqlite was 85 MB and
whose site was up.

FerretDB was unreadable BECAUSE it was up: SQLite has one writer, so the second
FerretDB the comparison started against the same directory did not get the data.
The tool then reported the database it had been talking to all along as
unreadable, and refused to choose.

The live one is asked first now - evidence only counts and sorts - and a
second copy is started only for a database that is not running. Both speak the
MongoDB wire protocol on the same port, so which one is answering is asked
rather than assumed: FerretDB names itself in buildInfo and a mongod does
not. Reading one as the other would be a wrong answer given with confidence,
which is worse than "unreadable".

Rules, My Cards, Due Cards and Global Search each keep their controls in the
shared page sidebar, and each draws them as .board-header-btn - which is what
they were when they lived in that page's own second header bar.

Every rule for that class is scoped to #header-quick-access, so inside the
sidebar they had NO styling at all. On the Rules page that is three bare links
jammed onto one line - "← Board 🔀 Workflow view ⇄ Import / export" - with the
icons run into the words and nothing to click but the text itself.

They are rows now: one per line, the width of the panel, with the icon in a
fixed column so every label starts at the same x, and a hover to click against -
the shape the board sidebar's own rows have. Both sidebars built on that shell
get it, All Boards' as well as the page one.

A hundred and fifty icons, eight to a row, in a popup 380 pixels wide: a column
taller than the screen, so choosing a sticker meant scrolling past most of them.

It is as wide as the colour pickers now - min(90vw, 720px) - and the picker
is a grid that fits as many columns as the width allows instead of stopping at
eight. The clamp that places a popup knows the new width too, or a popup opened
near the right edge would have landed half off screen.

Clicking a label opened the card's labels popup AND the card details behind it:
the click reached the minicard too, so one click did two things and the one
nobody asked for was underneath the one they did.

It stops at the label now. A click in the labels AREA that is not on a label is
still the card's, as before - and which label was clicked is read from the
EVENT rather than from :hover, which answers about the pointer and on a touch
screen can still be true for whatever was tapped last.

Everything about custom fields moved to the hamburger at the end of the card's
own Custom Fields heading - the picker of which fields are on this card, a
pencil each, and Add custom field - and the card menu's entry, the Board
Settings row and the wrapper popup went with it. But the heading itself was
drawn only when the card already HAD a custom field on it.

So the one way in existed only once you were already through it. A card with no
custom field had no heading and therefore no hamburger; a board that had never
used them had no way in anywhere, because the sidebar view that still holds the
create and edit forms is opened by nothing. It is invisible on any board that
already has a field - which is every board a developer tests on - and the
browser tests found it on a seeded board that had none.

The heading is drawn for every card its reader may write to now, the same
condition the rest of the editable card uses. The FIELDS below it still come
from the card's own values, so a card with none shows an empty section rather
than a phantom row per board definition, and a reader who may not write sees no
heading at all.

The anchor that used to open the old popup went too: the move took away its
label text and left the tag, so it rendered nothing, could not be clicked, and
still had two handlers bound to it. tests/customFieldsSectionMenu.test.cjs
gains the two checks that would have caught this - the heading is gated on who
may write rather than on what the card already has, and no empty anchor or
orphaned handler is left behind.

Two things wrong with the popup the Custom Fields heading opens.

A new field made from it never appeared. Add custom field sits OUTSIDE the
list of fields, so its data context is the popup's own - which is the CARD - and
the create and edit forms are one form that decided which it was doing by
whether its context had an _id. A card has one, so creating a field from a
card ran the UPDATE branch against a custom field whose id was a card's: no such
document, nothing written, and nothing said so. The same form works from the
board sidebar, where the context has no _id, which is why this only ever
happened from a card.

Both halves are fixed. The popup hands the form an empty context, because a new
field is made from nothing. And the form no longer trusts a bare _id: it asks
whether that id NAMES a custom field, so a context arriving from anywhere cannot
make it update one that is not there.

The pencil that edits a field sat on a line of its own under the field's name.
Every other pop-over list has ONE anchor per row, so the row is a block and the
anchor fills it - and two anchors in a block stack. This list has two by design,
the name with the checkbox that puts the field on this card and the pencil that
edits the field itself, so the row is the flex container now and the name takes
the space the pencil does not. Scoped to this popup, so no other list moves.

A pop-over draws its header from its title, and with no title it renders as
no-title: no header, no X, no back arrow - Escape or a click away are the only
ways out. Noticed on the question "Are you sure you want to delete this
background image?", which is the worst place for it.

Ten of them were in that state, and each is titled the way the other 151
already were: a <name>Popup-title key. Delete Background Image, Delete
Duplicate Lists, Delete Account, Add Domain, Remove Domain, Map to existing
user, Export swimlane, Export list, Export checklist, and the member popup.

They were added to EVERY language file at the same position, as the English
placeholder a pull would produce - the files are one key order, and a key
inserted in some and appended in others makes every later diff unreadable.

The other mechanism, Popup.open(name, { titleKey }), is not a second way but
the same one pointed at a phrase the app HAS - "Custom Fields", "Sort Boards",
"Show on Card" - so a word already translated 147 times is not copied into a
new key that would start as English in all of them.
tests/popupTitles.test.cjs walks every popup
template and fails if one resolves no title at all, so the next one cannot ship
without a header.

"Upload background image" picked a file and then nothing arrived. Two fields of
an upload's config are not optional in the way they look, and the board
background's config - written by hand - had neither:

• fileId, and the same id copied into meta.fileId. Attachments'
  namingFunction is what decides the name a file is STORED under, and on the
  client it reads that id out of meta and deletes it. Without it the name is
  undefined.
• transport. HTTP everywhere, because Meteor-Files' default DDP floods
  the WebSocket and makes Safari reconnect at ~95%; DDP on Sandstorm, whose
  http-bridge strips the x-* upload headers so every chunk comes back "Can't
  continue upload, session expired" [408].

Both come from one builder now, in
attachmentUploadConfig.js, used by the
card's file picker, the card's pasted image and the board background alike - so
the next uploader gets them by asking for a config rather than by knowing two
things nothing would have told it.

One popup answers the whole question now - the URL, the upload, and the
pictures uploaded to this board - and Board Settings / Board backgrounds is
gone with the popup it opened: a second entry to a list that is already on
screen is a second place to look for one thing. Clicking a PICTURE, or its
name, puts that one behind the board; it used to be a 14px check icon in the
row under an 80px picture of the thing it applies, so the obvious click did
nothing. Download and delete stay in that row, being the two things a picture
cannot say.

Three things around the upload made the failure impossible to read, and are
fixed with it. insertAsync can reject BEFORE there is an uploader to listen
to, and that rejection went nowhere: the spinner stopped, no message appeared,
and the picture simply never turned up. It is caught and shown now. Each
picture is listed with its NAME, because two photos are the same picture at 80
pixels and nothing said which one had arrived. And a finished upload puts
itself behind the board: "add background image" is asked for by somebody who
wants that picture there, and an upload that only lands in a list, with the
board unchanged, reads as one that did not work.

getInitials() ended with this.username[0], so a user document that arrived
without a username threw a TypeError - from a Blaze helper, mid-render. Two
helpers call it, so each avatar threw twice, and the second throw left the SVG's
viewBox half-written (0 0 15), which Firefox refuses outright: the avatar
drew nothing and took the rest of that render pass with it.

It is total now: initials, then a fullname, then the first letter of a username
if there is one, then an empty string - a blank circle rather than a broken
page. A fullname of only spaces used to spell the literal word "undefined" in
the circle, because an empty word still contributed its missing first letter;
empty words are skipped.

The dropdown that chooses a card's date format disappeared, and nothing brought
it back - the Received, Start, Due and End dates under the same heading were
there, but the selector above them was gone.

Two things were folding it. #1591
gave every FIELD of an opened card a caret on its own title and hid everything
after that title when it was clicked, storing the fold per card in the user's
profile. The section carets that replaced it put ONE handle on each section's
heading - and that heading is drawn on the first field of the section, so a
click on it was also a click on a field title. The old handler ran too, folded
that field, and stored it. Reopening the section brought the dates back but not
the field the heading sits on, and the per-field caret had been suppressed
inside a group, so there was nothing left to open it: the Date Format select
was hidden for good.

The #1591 half is gone - the handler, the caret it drew, the rule that hid the
siblings, and the per-card state it re-applied on render. Every field lives in
a section now, and the section's heading is the only handle. The same per-user
store still belongs to the CHECKLISTS, which key their own entries by checklist
id and are untouched; that is why the store itself stays.

Moving eleven sections with a script is how markup disappears without anything
failing: the file still compiles, the tests still pass, and a card is quietly
missing a row. Comparing the card against its state before the section work
turned up four things, three of them lost:

• the card button row (+cardButtons) - a slice used it as a boundary and
  swallowed it;
• a custom field's name: +cardCustomField renders the value and nothing
  else, so a card with three custom fields showed three values with nothing to
  say what they were;
• the attachment count beside the Attachments heading, which the board
  setting for it still governs;
• and one thing GAINED that should not have been: a second, bare + beside
  the End date's add button.

All four now have a test of their own, because each was invisible to everything
else.

The Copy card link to clipboard button carried only .btn, so it fell back
to the plain grey button whose dark label is nearly unreadable on a dark theme.
It is a .primary now - the board's accent with white text - named in the same
rules as the other themed buttons rather than given a copy of them.

Grouping the fields gave each group a header LINE of its own, and for a group
named after its first field that line said the same word twice, one above the
other: "Labels" and then "Labels, Stickers, Location".

There is one row of titles now, with the caret at the start of it: Labels
Stickers Location, Members Assignee Creator, and their + buttons on
the row below. The caret belongs to the first field's title rather than to a
header above it, and everything it folds - that field's own content and every
field beside it - is behind the same switch, so a collapsed group is exactly one
line.

The rule moved with it, from inside a field to the group, where it spans the
card. The Checklists icon is a plain check again rather than a check in a
box, which is what it was before it became a section.

Requested By and Assigned By were set by clicking the word "Add". They
have the round + the two fields beside them use now, opening the same editor
the text does.

Checking where else those two live turned up a round trip that lost them, which
is the worst shape this kind of bug takes - the export file looks complete and
the import reports success. They were exported by the card PDF, the card Excel
and the board CSV, and imported by NOTHING: a card exported and imported back
came home having forgotten who asked for it and who assigned it. Both importers
put them back now, our own JSON and .zip and the per-menu one.

The board's Excel TABLE did not export them at all, so that one gained two
columns - header and value together, since a header without its value shifts
every column after it.

And from other trackers, where the same idea has another name: Jira's
Reporter is who asked for the work, and an issue's author on GitHub,
Gitea, Forgejo and GitLab is the same thing. Both arrive as Requested By, as
free text, so they survive an import from a tracker nobody on this board has an
account on. A source with no such field - Trello, CSV - gains nothing, which a
negative test pins.

Grouping the fields left two things crooked. Members, Assignee and Creator were
each a full-width row, so Assignee and Creator fell to the line below Members -
the class that made a FIELD full width was from before the groups, and the group
is the full-width row now. And a field whose title had been taken over by the
group header had its + on the first line, level with its neighbours'
titles, instead of on the second line with theirs.

Every field in a group keeps its own title again. The group's header names the
family and folds it; the field's title names the field, and its content - the +,
the avatars - starts on the line under it, level all the way across.

The caret beside Labels folded the Labels field and left Stickers and
Location sitting under it, and every field had a caret of its own on the right -
#1591 draws one on each
.card-details-item - so a row could have two handles saying the same thing in
two sizes.

The fields belong to FAMILIES, and the families are what fold now:

• Labels - Labels, Stickers, Location
• Date Format - the format, Received, Start, Due, End
• Members - Members, Assignee, Creator, Requested By, Assigned By
• Dependencies
• Sort - Sort, List, Spent time

One caret per group, on its title, at the reading direction's start. The fields
inside a group have none: #1591's per-item caret is turned off there, and its
title is no longer a handle. Outside a group it is untouched, so nothing that
folded before stopped folding. A collapsed group is one line - the caret, the
icon and the name - because everything else is inside the fold.

Members reads Members, Assignee, Creator, which is the order it was asked
for. The loose rule the layout drew above the users block is gone with it: the
group's own rule is above the whole group, so there is one line there instead of
two.

Four small things about those separators, all of them visible at a glance and
none of them visible in the source.

The rule drew a border of its own, darker than the line the card already had
above Creator. It is that same lighter hr now - the section rule sets only its
spacing, so there is one line style on the card rather than two.

Labels had a rule above it. It is the first section: there is nothing above
it to be separated from. Members had one too, immediately under the rule the
layout already draws above Creator - two lines with a heading between them.
Neither draws one now, and every other section still does.

And the rule above Activities was to the LEFT of the heading rather than
above it, because .activity-title is display: flex and a rule inside it is a
flex item. The heading sits outside that row now.

Two things the collapsible sections got wrong the first time, both visible the
moment a card was opened.

Short rules everywhere. .card-details-items is a wrapping flex row, and
the
rule was drawn INSIDE a section - so it was as wide as that box, which is a stub
of a line beside a heading rather than a separator across the card. The six
sections that live in that row are now rows of their own, so the rule in them
spans the card, and the items that were laid out side by side on purpose -
Stickers, Location, the four dates, Creator, Assignees - still share rows as
they
did.

Two headings for one section. The Checklists and Subtasks templates draw
their own title, and the new section header drew it again, so a card showed each
of those names twice, one above the other. The templates keep what belongs to
the LIST - add a checklist, add a subtask - and the section header is the only
thing that names the section.

A card had ONE caret, in its header, which collapsed the whole card - and
Activities had an eye beside its heading. Every other section was a heading
with no control at all, and the rules between them were written by hand wherever
somebody remembered one.

Labels, Date Format, Members, Dependencies, Sort, Custom
Fields, Description, Checklists, Subtasks, Attachments,
Comments and Activities each carry a caret that collapses that section,
and one rule above it. Both come from ONE template, so eleven sections cannot
end
up with ten separators and nine carets. The heading is a real button - it
announces itself as one and Enter or Space works it - rather than a click target
only a mouse can find. The caret points DOWN when a section is open and toward
the way the reader reads when it is closed: right in English, left in Arabic,
Hebrew and Persian.

Activities starts collapsed and everything else open, because a card is
opened to read the card and its history is the thing you go looking for.

The eye is gone, and that needed one piece of care: it was NOT the same control
as the caret. showActivities: false - its default - subscribed to
activityType: 'addComment' only, so the eye chose between "comments" and "the
whole history" as much as it showed and hid. Removing it without more would have
quietly turned an opened Activities section into a comments-only list. So a card
section that is OPEN now asks for the whole history, and one that is closed
subscribes to nothing at all - which is the cheaper half of what the flag was
for, without a second control to keep in step. A card that had the flag
explicitly set to false keeps it.

Custom Fields is one section with one caret however many fields a card has: its
header was briefly inside the loop that draws them, which would have been six
sections sharing a caret on a card with six fields.

In an opened card's Dependencies section each row is an icon, the linked
card's title and its controls, and the title was held on one line with an
ellipsis. The card details pane is narrow and a card title is a sentence, so
most of a real title - everything to the right of the coloured icon - could not
be read at all.

It wraps now, and the row grows as tall as it needs to. Two properties, and the
second is the one that is easy to miss: white-space: normal alone would have
changed nothing, because a flex item's default min-width: auto refuses to
shrink below its content, so the text overflowed the row instead of wrapping
inside it. min-width: 0 is what lets it. A title that is one long token - a
URL, an id - breaks inside itself rather than pushing the type, colour and
remove controls off the row, and the icon and those controls now sit beside the
FIRST line instead of floating halfway down a three-line block.

Clicking a card's title opens the title editor in place of the card header - and
the header is where the card's own close X lives, so the X disappeared the
moment you started editing and Save became the only visible way out. Escape
still worked; nothing on the screen said so.

The editor draws the X itself now, reusing the header button's own class, so it
is the same size in the same place and does not jump as the editor opens and
closes. That class floats to inline-end, which is the right in English and the
left in Arabic, Hebrew and Persian without a second rule - so the mirroring
needs no direction branch and must not grow one.

The same one-line omission was in the Requested by and Assigned by
editors right below it: the close anchor was there, its icon was not, so the
click target existed and was invisible. They have their X now too.

#6586 was reopened for what the
first fix left: the PDF export of a card had grown separately from the Excel
export of the same card, and every point the reporter came back with was a
symptom of that. The labels were hard-coded English - "Assignee, Labels, due,...
these titels should be in the user set language". They were not even consistent
with each other: the card export wrote Due: , the board export wrote due
with no colon and a lowercase letter. And a card carries more than either export
printed - "I think all those other things we set in a card should be also
present
in the pdf? Location, Voting, Checklists, Subtasks, Custom Fields, Attachments,
Comments...".

Two exports of one card that disagree about what is on it are one bug reported
twice, so the fix is to stop them being two things. Both now carry the same
fields, in the same order, under the same i18n keys, in the language the request
carries: title, labels, creator, assignees, members, board, swimlane, list, card
number, requested by, assigned by, the six dates, spent time, description,
custom
fields, checklists, subtasks, comments, attachments, voting and Planning Poker.
The three sections neither export had - custom fields, voting and
poker - are new on both sides, selectable like the others in the Excel
export's field checkboxes, and appended to that list rather than inserted, so a
saved ?fields= link still asks for what it always asked for.

Inside the PDF exporters one field() helper writes every Label: value, which
is what makes the board export's "due" and the card export's "Due:" impossible
to
have at once again. Every label carries its English text as the fallback, so a
language that has not translated a key shows the word rather than the key.

"The marked due date - here the time is not in the user set timezone (-2h wrong
for Europe/Berlin)." It was worse than -2h: the PDF export printed UTC and the
Excel export printed whatever zone the server process was started in, so the
same
card could come out with two different times on it and neither was the reader's.

Dates are stored in UTC, and a WeKan profile carries no time zone at all, so the
only place the reader's zone exists is the browser. Every export link now sends
it - Intl.DateTimeFormat().resolvedOptions().timeZone, the IANA name the
server's own Intl wants back - together with the date format the opened card
is showing, which for a reader who is not logged in lives in localStorage
where no server-side lookup can reach it. An export that printed 2026-08-14
for
a card showing 14-08-2026 was the same card in two formats.

Both exports format through one helper, formatDateByUserPreference, which
gained an optional zone; without one it still renders in the process's own zone,
which is what every client-side caller - the card view itself - wants. A
server-built export that is given no zone renders UTC and SAYS UTC, rather than
printing the server's and looking like the reader's. The route accepts only the
three formats that helper understands, and a zone name is length-bounded: they
are request parameters, not free text. 12:00Z now prints as 14:00 for
Europe/Berlin, as 00:00 on the 15th for Pacific/Auckland, and a zone the
runtime does not know falls back instead of failing the download.

"Would it make sense to support markdown formated text in description? (so it
gets transformed correct in the pdf output with bold, underline,....)" The first
fix removed the syntax and kept the words, because **bold** in a PDF is four
stray asterisks; this is the other half.

A description is now cut into RUNS - **bold** into a bold run, *italic* into
an italic one, ***both*** into both, nested emphasis keeping both - and each
is
drawn in the matching Courier face: Courier, Courier-Bold, Courier-Oblique,
Courier-BoldOblique, all base-14, so no font binary is embedded. Nothing is
measured to place them: consecutive Tj operators continue at the current text
position, so a font switch between two of them lands the next run exactly where
the last ended, whatever the glyph widths are. Wrapping counts characters across
the whole line, indent included, so an emphasised word does not push a line past
the page.

What has no face is not invented: ~~strikethrough~~ and `code` keep
their
words and lose their markers, because a base-14 Type1 font has no strike and
there is no fifth Courier to give code. Block markdown is still flattened either
way - a heading loses its # and is drawn in the bold font, a bullet keeps one
shape, a fence keeps its code. An underscore inside a word stays an underscore:
file_name_here is an identifier, not three-quarters of an italic.

imports/i18n/data/ is 37 MB across 246 files, every one of them reachable from
the client. The only thing keeping them out of the initial bundle is that each
entry in imports/i18n/languages.js loads its file through
() => import('./data/<tag>.i18n.json') - a call Meteor's dynamic-import
package code-splits into a module fetched on demand - and that tap.js imports
exactly ONE of them statically, English, so the interface stays readable when
dynamic import is broken (#6503).

That was true when checked and nothing pinned it. A single
import data from './data/xx.i18n.json' added anywhere on the client would
quietly ship that language to every visitor, and nothing about the app would
look wrong - it would just be a heavier download, which no other test measures.

tests/i18nLazyLoading.test.cjs checks the six things that have to hold
together: every registered language has a dynamic loader, languages.js pulls
in no data itself, tap.js statically imports English and nothing else, the
loader is called once for the single resolved tag rather than mapped over the
registry, no client file bundles a language file, and dynamic-import is still
in .meteor/packages. A negative test proves the detector really sees a static
import, so the other checks cannot pass by failing to look.

A run failed the same four tests in Chromium and in Firefox, and three of the
four were the guard describing the OLD markup rather than the app being wrong.

editTitle waited for both js-card-title and js-open-inlined-form on ONE
element. The title splits now - the leading half opens the editor and the rest
of the heading drags the window - so the class is a DESCENDANT of the title, and
the old selector matched nothing and waited out its timeout.

The Activities heading in the board sidebar carries TWO icons since the caret
became shared with the card sections: the caret that says whether the section is
open, and the section’s own comment icon. A bare i.fa matches both, which
Playwright fails as a strict-mode violation rather than picking one. The spec
asks for the caret specifically now - the three directions caretClassFor can
produce - which is also a stronger assertion, since the caret is the part that
indicates state.

The fourth