Motivated by the 10.16-10.21 reports where, after an upgrade, the login page
showed "Must be logged in" or sat on the logo + "Loading, please wait." spinner,
pages took 5+ minutes, All Boards counts stayed 0 and i18n showed raw keys — the
FerretDB v1 (SQLite) process pegged ~2 cores for a long time under WeKan's poll
load, i.e. a migration/repair or a saturated backend, with no way to see it
without the Admin Panel.
Server-side, independent of any client / progress page:
- server/startup/repairBoardsOnStartup.js runs the shared board data-repairs once
(version-gated, background, 30s after boot) so corrupted data is fixed even if
no user opens a board and nobody watches a progress page.
- The MongoDB <-> SQLite text migration and the startup repair now PERSIST their
progress to the text_migration_status collection (models/textMigrationStatus.js),
so a separate process can see "a migration/repair is in progress" (an in-memory
object could not).
Status overview (server/lib/systemStatus.js), shown in Admin Panel / Problems ->
Summary and via the method systemStatusReport (admin-gated, server/methods/
systemStatus.js):
- everything in progress (text migration, board repair, recovery, cron migration,
attachment migration) aggregated from the persisted status collections;
- detected problems (broken cards; failing login-page checks);
- login-page "Must be logged in" / "Loading, please wait" cause checklist
(migration in progress, ROOT_URL, LDAP, Sandstorm) — models/lib/loginProblems.js;
- a CPU detail area that calls out a pegged ferretdb process and the mitigation.
Snap: `snap run wekan.problems` (snap-src/bin/wekan-problems[.mjs], snapcraft app
`problems`) prints the same overview as text — problems, migrations/repairs in
progress, login checks — so an admin with only server access can see it WITHOUT
Admin Panel access. Sub-commands: migrations | login | broken-cards | cpu | help.
Pure helpers models/lib/loginProblems.js and models/lib/problemsOverview.js are
unit-tested; tests/problemsStatus.test.cjs (14 checks) also source-guards the
server hub, method, startup pass, migration persistence and snap command.
Thanks to xet7 !
The board-open self-heal is broadened from the #6484 list-unbind alone to a
shared repair set (models/lib/boardRepair.js planner + server/lib/repairBoardData.js):
- #6484: lists wrongly bound to a swimlane -> cleared back to board-wide, so the
list stops "disappearing" from the other swimlanes;
- cards with no swimlaneId (null/''/missing), which never render in the Swimlanes
view -> assigned to the board's first swimlane;
- orphaned cards whose swimlaneId points at a DELETED swimlane (invisible cards)
-> reassigned to the first swimlane. A card on an existing but archived swimlane
is NOT treated as orphaned.
The same repair set now runs in BOTH places:
- Board open: boardBody.js maybeRepairBoard -> boardRepairNeeded / repairBoardData
(server/methods/repairBoardData.js), once per board, admin-gated, fire-and-forget.
- MongoDB <-> FerretDB v1 (SQLite) text migration: migrateTextDatabase runs
repairAllBoards() on the live database BEFORE copying, so the migrated copy is
clean too. It reports a new "repairing" phase (boardsDone/boardsTotal/repaired).
Both flows drive ONE shared progress dashboard (migrationProgress), now:
- mounted app-wide (defaultLayout) so it shows for an Admin Panel database
migration as well as a board-open repair;
- fed from the DB-migration status poll (attachments.js driveMigrationDashboard);
- styled in WeKan blue (#2980b9) instead of the old purple/green;
- branded with the configured Product name (from the earlier commit).
Tests: tests/boardRepair.test.cjs (planner + server/migration/dashboard source
guards, 11 checks) and the updated tests/listUnbindRepair.test.cjs pass.
Thanks to xet7 !
Adds a "Database migration" section to Admin Panel / Attachments with two buttons:
migrate text-based data (everything except attachments/avatars, which stay on the
filesystem) to FerretDB v1 (SQLite), or back to MongoDB.
WeKan is connected to one database at a time, so the new server methods open a
SECOND driver connection to the OTHER database (both MongoDB and FerretDB v1 speak
the MongoDB wire protocol) and copy the text collections from the live database
into it, upserting by _id (idempotent, re-runnable). The target URL is
WEKAN_FERRETDB_URL (default mongodb://127.0.0.1:27018/wekan) or WEKAN_MONGODB_URL
(default mongodb://127.0.0.1:27019/wekan); both must be running. Progress is polled
via migrateTextDatabaseStatus and shown live. After it finishes, point MONGO_URL at
the other database and restart (on Snap: snap set wekan database=ferretdb / =mongodb).
Admin-only. Attachments/avatars are skipped (they live on the filesystem).
Thanks to xet7.
Lauri Ojansivu