summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorMaxime Quandalle <maxime@quandalle.com>2015-10-13 14:17:53 +0200
committerMaxime Quandalle <maxime@quandalle.com>2015-10-13 14:17:53 +0200
commite504ac28940f614652f8e414aa0a67f60985bb89 (patch)
treeb6363323fb60485bdc66bc27ead10f79211c392a
parentbf46a214050cf468d2b08436a8d070ed5c24c852 (diff)
downloadwekan-e504ac28940f614652f8e414aa0a67f60985bb89.tar.gz
wekan-e504ac28940f614652f8e414aa0a67f60985bb89.tar.bz2
wekan-e504ac28940f614652f8e414aa0a67f60985bb89.zip
Enforce "public" visibility for Sandstorm boards
Fixes #346
-rw-r--r--sandstorm.js9
-rw-r--r--server/migrations.js6
2 files changed, 15 insertions, 0 deletions
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