Browse Source

Enforce "public" visibility for Sandstorm boards

Fixes #346
Maxime Quandalle 9 years ago
parent
commit
e504ac2894
2 changed files with 15 additions and 0 deletions
  1. 9 0
      sandstorm.js
  2. 6 0
      server/migrations.js

+ 9 - 0
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) {

+ 6 - 0
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