docs/ImportExport/AttachmentBackwardCompatibility.md
This document describes the backward compatibility implementation for Wekan attachments, allowing the system to read attachments from both the old CollectionFS structure (Wekan v6.09 and earlier) and the new Meteor-Files structure (Wekan v7.x and later).
When Wekan migrated from CollectionFS to Meteor-Files (ostrio-files), the database structure for attachments changed significantly. This backward compatibility layer ensures that:
cfs_gridfs.attachments.filescfs.attachments.filerecordcfs_gridfs.attachmentsattachmentsmodels/lib/attachmentBackwardCompatibility.js
models/attachments.js
imports/reactiveCache.js
server/routes/legacyAttachments.js
/cfs/files/attachments/:idserver/migrations/migrateAttachments.js
getAttachmentWithBackwardCompatibility(attachmentId)getAttachmentsWithBackwardCompatibility(query)getOldAttachmentData(attachmentId)getOldAttachmentStream(attachmentId)The system automatically falls back to the old structure when:
Old attachment download URLs (/cfs/files/attachments/:id) continue to work and are handled by the legacy route.
Users can optionally migrate their old attachments to the new structure using the migration methods:
// Migrate a single attachment
Meteor.call('migrateAttachment', attachmentId);
// Migrate all attachments for a card
Meteor.call('migrateCardAttachments', cardId);
// Check migration status
Meteor.call('getAttachmentMigrationStatus', cardId);
To test the backward compatibility:
Old attachments not showing
Download failures
Performance issues
Enable debug logging by setting:
console.log('Legacy attachments route loaded');
This will help identify if the backward compatibility layer is properly loaded.
For users who want to fully migrate to the new structure:
The backward compatibility layer ensures that migration is optional and can be done gradually.