“you now can click outside your mini card and the popout will close. Clicking the mini card again to close the popout is still not possible I think” - #6465, on v10.90, which already had the toggle and a test suite pinning it.

The toggle was closing the wrong thing. On a desktop-sized screen the card details are not the address you are at: clicking a minicard writes the card id into the openCards session list and the board renders one draggable window per id in it, leaving the URL on the board. The toggle asked whether the card was currentCard and closed it by navigating to the board - which clears currentCard and leaves the window on screen, because nothing had taken the card OUT of openCards. Only the window’s own X button did that, which is why closing worked from the card and not from the minicard.

Both questions are now the card details’ own close logic, so both ways of closing a card do the same thing. “Already open” is asked of the list that renders the window, which also fixes it for Open many cards at once: with several open, currentCard is only the last one clicked, so every earlier window was impossible to close from its minicard. Closing navigates back to the board only when the card really IS the address - a card opened by a click is not, and navigating would reset the board view for nothing.

Two things in Member Settings / Change color.

Beside Default (no override), on the same row, a second switch: All Boards. Turned on, every tile in the All Boards overview takes the theme’s lighter colour — a white veil over the theme accent, which is one shade up from whatever the theme is — with white text on it, instead of the colour its own board was given. Turned off, which is the default, the overview is exactly what it was. A board with a background image keeps its image: that is a picture somebody chose, not a colour.

That is #6593’s observation as a per-user choice rather than a stylesheet. The pull request paints every tile white for everybody, and what it noticed is right — a wall of boards in eleven colours reads as a palette rather than a list — but “the tile colours are noise” and “the tile colours are how I find my board” are both true, of different people. So it lives where the rest of that user’s theme is chosen, and only there: a board has no overview of its own, and a site admin does not choose this for everybody.

And the highlighted row in a popup: it was filled with a fixed dark navy that appears nowhere else in WeKan and stayed navy however the user had themed it. The All Boards left menu fills its selected row with the theme accent and turns the label and icon white, and so does the Admin Panel — the popup does now too, so there is one selected-thing look rather than three.

“We upgraded from 10.85 to 10.89 and later to 10.90 - a reload of wekan got a timeout (loading forever)” - #6592.

WeKan does not open its web port until the database answers, and the snap’s two waits are endless on purpose: a database can take minutes to come up after an update, and giving up on it would be worse than waiting. They are not silent either - after two minutes each prints what to check. But nothing was listening on the web port while they waited, so the browser got a timeout and everything printed went to snap logs, which is the last place somebody whose site is down thinks to look. It also makes the two possible faults look the same: “WeKan does not load” is the report whether WeKan is broken or FerretDB simply did not start.

The wait now serves a page saying WeKan is waiting for its database, naming the database it is waiting for and, in the browser, the commands that answer why: the service’s own log (an exec format error is the bundled binary not running on this CPU), wekan.problems for which copy of the data is served, snap start --enable for a service left stopped by a failed migration, and snap revert back to the revision that worked. It refreshes itself away when WeKan starts, appears only after 30 seconds so an ordinary restart never shows it, and is stopped before anything else binds the web port.

This does not say why the reporter’s database did not come up - the issue has no logs yet - but the next person sees the reason instead of a timeout.

Two reports from a server running 10.90 Snap, both full of things that never happened.

Filesystem integrity, over and over: “the previous run STOPPED WITHOUT SHUTTING DOWN CLEANLY, and this server was down for about 4 minute(s)”, severity high — on a snap that had been refreshed, not crashed. Two faults, and the second made the downtime real rather than merely reported. IntegrityKeys.update() is not synchronous in Meteor 3: it starts a write and hands back a promise nobody waited for, so the clean-shutdown mark was never on disk when the process went. And registering ANY listener for SIGTERM replaces Node’s default behaviour, which is to terminate — nothing in that listener exited, so WeKan ignored SIGTERM outright, systemd waited out its stop timeout and used SIGKILL. That is both the minutes of “downtime” in those rows and a genuinely unclean kill on every ordinary restart. The mark is written with updateAsync now and the handler exits: with 0, after at most two seconds, and exactly once however many signals arrive. What a crash IS was not touched — the rows were wrong because the input was wrong.

Security Report, over and over: a medium-severity spoofing row for /metrics denied “with X-Forwarded-For present”, from 127.0.0.1. Every reverse proxy adds that header to everything it forwards, so a Prometheus scrape through a local proxy on a server whose allowlist does not cover it was being written up as an attack, in the report where a real one would have to be noticed. The spoof has a signature and it is asked for now: the header NAMES an allowlisted address while the connection is not from one. The 401 is unchanged and gained the sentence the admin needs — the address in it is the proxy, not the scraper, unless METRICS_TRUST_PROXY says how many hops to trust.

The snap’s standalone pages — under maintenance, recovering data, database too old, and the new one above — are a small HTTP server with no database connection, which is the whole point of them. The product name therefore comes from a file that wekan-control cached once per start, which leaves the case that matters: the name is set in the Admin Panel and the snap is not restarted before the next outage, so a rebranded WeKan tells its users “WeKan is waiting for its database” — a word they have never seen. WeKan is the only thing that knows the name the moment it changes, so WeKan writes it, at startup and whenever the setting changes.

They also wear the schema-upgrade dashboard’s colours now — the same #111 ground, #7bf blue and monospace face — because that dashboard and these pages are the same thing to a reader: the product saying what it is doing while it cannot show them the app.

“error: cannot find app “database-compare” in “wekan”. It seems, that database compare is not included in wekan 10.82” - #6583. It is not: the two recovery commands are snap apps, so they exist only in the revision that ships them, v10.90. That is the smaller half.

The larger half is what happened before it. The same instance, serving data from a migration done in July, ran snap run wekan.problems and was told “No problems detected” - which was true of everything it checks, because it reads the one database WeKan is connected to and every check inside it passed. Nothing asked WHICH of the two copies that is, while the documentation already claimed this command answered it.

The report now ends with a Databases on this machine section: which copy is being served and why, whether MongoDB files and a FerretDB database both exist, and - when they do - the two commands to run. It reads the files rather than a database, so it answers with WeKan down, and it declares no fault: two copies is the normal state of a migrated snap. A revision without the commands says to refresh rather than leaving snapd’s “cannot find app” as the last word, and says why a refresh is safe here - it does not import an old MongoDB over a FerretDB already in use, and neither copy is ever deleted. wekan.help and Migration-to-FerretDB.md list both commands with the release they arrived in.

Both sat in TODO Later as “needs the running app”, and both are decided by files that can simply be read.

#5052 — “Attachments cannot be opened (.eml)”, a blank page in the browser and nothing usable in Thunderbird after a board was copied. Three things could produce that, and each is handled now. The NAME: an unknown MIME used to append .bin (#6589), and Thunderbird will not open a .bin; every type a mail file arrives as now keeps its extension, and the board copy names copies with the same rule. The SERVING: message/rfc822 is in neither the dangerous-types nor the safe-inline list, so it takes the “unknown types” branch, which forces the download under the file’s own name — inline is what shows a browser a blank page. The FILE: an attachment whose recorded path and on-disk name had diverged is found by the same search reading already used (#6589), so a copied board’s attachments open even when the database’s idea of the path is stale.

#5081 — “Owner is on the very left, followed by members (if there are any) and on the very right there are the assignees”, wrapping to a second right-aligned row when they do not fit. That is what the current minicard renders, and the reason is the float: three groups that float to the inline end are laid out RIGHT to left in DOM order, so the markup’s assignees, members, creator renders as creator | members | assignees. Each avatar floats too, so a row that does not fit wraps and stays right-aligned, and an empty group is display: none rather than a gap.

tests/openIssuesVerifiedFromCode.test.cjs holds both, so neither can quietly stop being true.