wekan

The Open Source kanban (built with Meteor). Keep variable/table/field names camelCase. For translations, only add Pull Request changes to wekan/i18n/en.i18n.json , other translations are done at https://transifex.com/wekan/wekan only.

real-time javascript foss meteor docker-image wekan kanban sandstorm snapcraft

History

Lauri Ojansivu a86a087915 New features: - Admin Panel / Attachments: "Calculate file counts" on every storage backend, shown right below the "Read" toggle. Azure Blob Storage and Google Cloud Storage now have a "Calculate file counts" button (new `getAzureStorageStats` / `getGcsStorageStats` methods) that reports how many attachments and avatars are stored on that backend, matching what Filesystem, MongoDB GridFS and S3 already offer. The count is read from the stored file metadata (fast, no cloud API calls). The S3 button was also moved up to sit directly under its "Read" checkbox, so all backends are consistent. Thanks to Claude. - Admin Panel / Attachments: bilingual, self-documenting cloud-storage fields (S3, Azure and Google Cloud Storage). Each cloud-storage setting now guides the admin from top to bottom with both English and translated text, so it is easy to follow along while clicking through the provider's Cloud Console: - the field label uses the provider's own console wording in English (e.g. Access key ID, Secret access key, Storage account key, Service account key (JSON)), with the translated label shown below it; - a literal example of what the value should look like (e.g. `eu-west-1`, an example bucket name / endpoint / connection string), which is intentionally not translated; - a short description of the value, in English and then translated; - the Cloud Console menu path showing exactly where to find or create the value (e.g. AWS Console → IAM → Users → your user → Security credentials → Access keys → Create access key; Azure Portal → Storage accounts → your account → Access keys → key1; Google Cloud Console → IAM & Admin → Service accounts → … → Keys → Add key → Create new key → JSON), again in English and then translated. The provider field names, examples and menu paths are kept in English so they match what the Cloud Console actually shows, while the descriptions and menu paths are also translatable; section titles, the enable/read/force-path-style checkboxes and the Test/Save buttons remain fully translated. Thanks to Claude. - Admin Panel / Attachments / Move Attachment: "Repair file locations" button and a persistent "last move" message. The new Repair file locations button scans all attachments and avatars and finds any whose recorded storage (`versions.<v>.storage` / `path` / `meta.gridFsFileId`) no longer matches where the binary actually is — left inconsistent by an interrupted or failed move — and fixes the database to point at the real location: it detects the binary in GridFS (by the `metadata.fileId` stamped on upload, recovering files whose GridFS id reference was lost) or on the filesystem (using the storage strategy's own thorough path resolution, so the repair agrees with what a real download/move would find even when `versions.<v>.path` is stale), then corrects `storage`, `path` and `meta.gridFsFileId` accordingly. Cloud-stored files are left untouched, and files found nowhere are reported as "Not found". The scan is streamed (memory-safe) and shows a per-scope searched / repaired / not-found summary. Separately, after a move finishes the page now keeps showing the last move operation — source → destination (scope) and the date/time as `YYYY-MM-DD HH:MM:SS` — so it is clear what was last done. Thanks to Claude. New fixes: - Fixed moving attachments to S3 (and other cloud storage) failing and crashing the server. Uploading to S3 failed two ways, each of which crashed the whole server because the rejection was unhandled and SyncedCron treats those as fatal. The `@tweedegolf/sab-adapter-amazon-s3` adapter uploaded with a `PutObjectCommand` whose `Body` was a live stream: (1) with no `ContentLength` the AWS SDK fell back to a chunked signed upload that needs a decoded content length, which was undefined for a stream of unknown size — `Invalid value "undefined" for header "x-amz-decoded-content-length"`; and (2) if the socket dropped mid-upload (`socket hang up`), the SDK's body-stream promise rejected unhandled. Fixed by uploading the file as a complete in-memory buffer (`addFileFromBuffer`) instead of a live stream: a buffer has a known length (no content-length error) and no socket-bound stream to re-reject. The cloud upload promise now never rejects — any failure is captured and exposed via `waitUntilStored()`, which `moveToStorage` checks inside a try/catch so a failed upload leaves the source file intact and is logged cleanly. (Files are moved one at a time, so peak memory is one file.) Thanks to Claude. - Fixed `TypeError: Cannot read properties of undefined (reading 'on')` when moving attachments between Meteor-Files/GridFS and Filesystem. If a file's source binary was missing at its recorded location (e.g. a file left half-moved by an earlier interrupted run — storage says "gridfs" but the GridFS id reference is gone, or a filesystem path that no longer exists), `getReadStream()`/`getWriteStream()` returned `undefined` and `moveToStorage` (and `copyFile`) called `.on()` on it, throwing. Both now detect a missing read/write stream, log a clear message (which file, version, from→to storage, and why), skip that file and leave the source intact so no data is lost, and continue with the rest. Use the new "Repair file locations" button to fix the underlying inconsistent records. Thanks to Claude. - Fixed moving attachments/avatars from CollectionFS to Meteor-Files crashing the server, hanging the Admin Panel move at "File 1 / N", and leaving broken avatars. Three problems in Admin Panel / Attachments / Move Attachment: - Server crash on the first file (`uncaughtException: TypeError: Cannot read properties of undefined (reading '_id')` at `AttachmentStoreStrategyGridFs.writeStreamFinished`). The current mongodb driver's GridFS `GridFSBucketWriteStream` `'finish'` event no longer passes the stored file document, so `finishedData._id` threw and killed the process (which is also why the move appeared stuck at "File 1 / 4" — the background job died mid-file and its persisted status was frozen). The GridFS strategy now reads the uploaded file id from the write stream itself (`gridFSFile._id` / `id`), the `'finish'` handler is wrapped so it can never crash the process, and a startup reconciliation clears a stale "running" move status left by a crashed run so the UI un-sticks and a new move can be started. - Broken avatar after migrating avatars. The bulk move only repointed card cover references (`cards.coverId`); a user's `profile.avatarUrl` still pointed at the deleted legacy `/cfs/files/avatars/<oldId>` URL, so the avatar rendered broken. The move now repoints `profile.avatarUrl` to the migrated avatar (`remapReferences` handles avatars), and migrated files stamp `meta.migratedFromId` so references can be repaired to the exact new file. The startup repair in `server/models/users.js` (previously a no-op: it string-replaced the URL prefix while keeping the now-deleted id and never saved the document) now points each affected user's avatar at their migrated Meteor-Files avatar — matched precisely by `meta.migratedFromId`, otherwise strictly by `userId` (newest migrated avatar first), so a user can only ever be given their own avatar, never another user's. - `ObjectID` deprecation warning from `models/lib/grid/createObjectId.js` (`MongoInternals.NpmModule.ObjectID` → `ObjectId`). Thanks to Claude and xet7 !	5 days ago
..
createBucket.js	…
createObjectId.js	New features:	5 days ago

Lauri Ojansivu a86a087915 New features:

- **Admin Panel / Attachments: "Calculate file counts" on every storage backend,
  shown right below the "Read" toggle.** Azure Blob Storage and Google Cloud
  Storage now have a "Calculate file counts" button (new `getAzureStorageStats` /
  `getGcsStorageStats` methods) that reports how many attachments and avatars are
  stored on that backend, matching what Filesystem, MongoDB GridFS and S3 already
  offer. The count is read from the stored file metadata (fast, no cloud API
  calls). The S3 button was also moved up to sit directly under its "Read"
  checkbox, so all backends are consistent. Thanks to Claude.
- **Admin Panel / Attachments: bilingual, self-documenting cloud-storage fields
  (S3, Azure and Google Cloud Storage).** Each cloud-storage setting now guides
  the admin from top to bottom with both English and translated text, so it is
  easy to follow along while clicking through the provider's Cloud Console:
  - the field **label** uses the provider's own console wording in English
    (e.g. *Access key ID*, *Secret access key*, *Storage account key*,
    *Service account key (JSON)*), with the translated label shown below it;
  - a literal **example** of what the value should look like
    (e.g. `eu-west-1`, an example bucket name / endpoint / connection string),
    which is intentionally not translated;
  - a short **description** of the value, in English and then translated;
  - the **Cloud Console menu path** showing exactly where to find or create the
    value (e.g. *AWS Console → IAM → Users → your user → Security credentials →
    Access keys → Create access key*; *Azure Portal → Storage accounts → your
    account → Access keys → key1*; *Google Cloud Console → IAM & Admin →
    Service accounts → … → Keys → Add key → Create new key → JSON*), again in
    English and then translated.
  The provider field names, examples and menu paths are kept in English so they
  match what the Cloud Console actually shows, while the descriptions and menu
  paths are also translatable; section titles, the enable/read/force-path-style
  checkboxes and the Test/Save buttons remain fully translated. Thanks to Claude.
- **Admin Panel / Attachments / Move Attachment: "Repair file locations" button
  and a persistent "last move" message.** The new **Repair file locations** button
  scans all attachments and avatars and finds any whose recorded storage
  (`versions.<v>.storage` / `path` / `meta.gridFsFileId`) no longer matches where
  the binary actually is — left inconsistent by an interrupted or failed move —
  and fixes the database to point at the real location: it detects the binary in
  GridFS (by the `metadata.fileId` stamped on upload, recovering files whose
  GridFS id reference was lost) or on the filesystem (using the storage
  strategy's own thorough path resolution, so the repair agrees with what a real
  download/move would find even when `versions.<v>.path` is stale), then corrects
  `storage`, `path` and `meta.gridFsFileId` accordingly. Cloud-stored files are
  left untouched, and files found nowhere are reported as "Not found". The scan is
  streamed (memory-safe) and shows a per-scope searched / repaired / not-found
  summary. Separately, after a move finishes the page now keeps showing
  the last move operation — source → destination (scope) and the date/time as
  `YYYY-MM-DD HH:MM:SS` — so it is clear what was last done. Thanks to Claude.

 New fixes:

- **Fixed moving attachments to S3 (and other cloud storage) failing and
  crashing the server.** Uploading to S3 failed two ways, each of which crashed
  the whole server because the rejection was unhandled and SyncedCron treats
  those as fatal. The `@tweedegolf/sab-adapter-amazon-s3` adapter uploaded with a
  `PutObjectCommand` whose `Body` was a live stream: (1) with no `ContentLength`
  the AWS SDK fell back to a chunked signed upload that needs a decoded content
  length, which was undefined for a stream of unknown size — `Invalid value
  "undefined" for header "x-amz-decoded-content-length"`; and (2) if the socket
  dropped mid-upload (`socket hang up`), the SDK's body-stream promise rejected
  unhandled. Fixed by uploading the file as a complete in-memory **buffer**
  (`addFileFromBuffer`) instead of a live stream: a buffer has a known length (no
  content-length error) and no socket-bound stream to re-reject. The cloud upload
  promise now never rejects — any failure is captured and exposed via
  `waitUntilStored()`, which `moveToStorage` checks inside a try/catch so a failed
  upload leaves the source file intact and is logged cleanly. (Files are moved one
  at a time, so peak memory is one file.) Thanks to Claude.
- **Fixed `TypeError: Cannot read properties of undefined (reading 'on')` when
  moving attachments between Meteor-Files/GridFS and Filesystem.** If a file's
  source binary was missing at its recorded location (e.g. a file left
  half-moved by an earlier interrupted run — storage says "gridfs" but the
  GridFS id reference is gone, or a filesystem path that no longer exists),
  `getReadStream()`/`getWriteStream()` returned `undefined` and `moveToStorage`
  (and `copyFile`) called `.on()` on it, throwing. Both now detect a missing
  read/write stream, log a clear message (which file, version, from→to storage,
  and why), **skip that file and leave the source intact** so no data is lost,
  and continue with the rest. Use the new "Repair file locations" button to fix
  the underlying inconsistent records. Thanks to Claude.
- **Fixed moving attachments/avatars from CollectionFS to Meteor-Files crashing
  the server, hanging the Admin Panel move at "File 1 / N", and leaving broken
  avatars.** Three problems in Admin Panel / Attachments / Move Attachment:
  - **Server crash on the first file** (`uncaughtException: TypeError: Cannot read
    properties of undefined (reading '_id')` at
    `AttachmentStoreStrategyGridFs.writeStreamFinished`). The current mongodb
    driver's GridFS `GridFSBucketWriteStream` `'finish'` event no longer passes
    the stored file document, so `finishedData._id` threw and killed the process
    (which is also why the move appeared stuck at "File 1 / 4" — the background
    job died mid-file and its persisted status was frozen). The GridFS strategy
    now reads the uploaded file id from the write stream itself (`gridFSFile._id`
    / `id`), the `'finish'` handler is wrapped so it can never crash the process,
    and a startup reconciliation clears a stale "running" move status left by a
    crashed run so the UI un-sticks and a new move can be started.
  - **Broken avatar after migrating avatars.** The bulk move only repointed card
    cover references (`cards.coverId`); a user's `profile.avatarUrl` still pointed
    at the deleted legacy `/cfs/files/avatars/<oldId>` URL, so the avatar rendered
    broken. The move now repoints `profile.avatarUrl` to the migrated avatar
    (`remapReferences` handles avatars), and migrated files stamp
    `meta.migratedFromId` so references can be repaired to the **exact** new file.
    The startup repair in `server/models/users.js` (previously a no-op: it
    string-replaced the URL prefix while keeping the now-deleted id and never
    saved the document) now points each affected user's avatar at their migrated
    Meteor-Files avatar — matched precisely by `meta.migratedFromId`, otherwise
    strictly by `userId` (newest migrated avatar first), so a user can only ever
    be given their own avatar, never another user's.
  - **`ObjectID` deprecation warning** from `models/lib/grid/createObjectId.js`
    (`MongoInternals.NpmModule.ObjectID` → `ObjectId`).

Thanks to Claude and xet7 !

5 days ago

createBucket.js

…

createObjectId.js

New features:

5 days ago