From e504ac28940f614652f8e414aa0a67f60985bb89 Mon Sep 17 00:00:00 2001 From: Maxime Quandalle Date: Tue, 13 Oct 2015 14:17:53 +0200 Subject: Enforce "public" visibility for Sandstorm boards Fixes #346 --- sandstorm.js | 9 +++++++++ server/migrations.js | 6 ++++++ 2 files changed, 15 insertions(+) diff --git a/sandstorm.js b/sandstorm.js index 97d42bdf..b0039d63 100644 --- a/sandstorm.js +++ b/sandstorm.js @@ -101,6 +101,15 @@ if (isSandstorm && Meteor.isServer) { updateUserPermissions(doc._id, doc.services.sandstorm.permissions); }); + + // LibreBoard v0.8 didn’t implement the Sandstorm sharing model and instead + // kept the visibility setting (“public” or “private”) in the UI as does the + // main Meteor application. We need to enforce “public” visibility has the + // sharing is now handled by Sandstorm. + // See https://github.com/wekan/wekan/issues/346 + Migrations.add('enforce-public-visibility-for-sandstorm', () => { + Boards.update('sandstorm', { $set: { permission: 'public' }}); + }); } if (isSandstorm && Meteor.isClient) { diff --git a/server/migrations.js b/server/migrations.js index 05f5ff7d..509d8510 100644 --- a/server/migrations.js +++ b/server/migrations.js @@ -4,6 +4,12 @@ // // Migrations.add(name, migrationCallback, optionalOrder); +// Note that we have extra migrations defined in `sandstorm.js` that are +// exclusive to Sandstorm and shouldn’t be executed in the general case. +// XXX I guess if we had ES6 modules we could +// `import { isSandstorm } from sandstorm.js` and define the migration here as +// well, but for now I want to avoid definied too many globals. + // In the context of migration functions we don't want to validate database // mutation queries against the current (ie, latest) collection schema. Doing // that would work at the time we write the migration but would break in the -- cgit v1.2.3-1-g7c22