2018-04-06 19:19:45 +03:00
|
|
|
'use strict';
|
|
|
|
|
|
|
|
const Promise = require('bluebird'),
|
2017-12-12 00:47:46 +03:00
|
|
|
_ = require('lodash'),
|
|
|
|
uuid = require('uuid'),
|
|
|
|
crypto = require('crypto'),
|
🎨 ⏱ Cleanup / optimise the server.init() function (#7985)
refs #2182
* 🔥 Remove unused options from server init
- this is left over from old code and is now unused
* 🎨 Move knex-migrator check to db health
- Move complex check function into own module
- Call module from server/index.js
- This just improves the readability of server/index.js
* 🔥 Remove old comments
- These comments all make no sense now!
* 🎨 ⏱ Move model init out of promise chain
- Model.init() does not return a promise
- Therefore, we can move it to the top of the init function, outside of the promise change
- This should be a minor optimisation, and again improves readability /clarity of what's happening
* ✨ ⁉️ Move DBHash init / first run to Settings model
- this structure is left over from when we had code we executed on the first run of Ghost
- the implementation used the API to initialise one setting before populateDefaults is called
- this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work
- the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults()
- it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!)
- perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁
* ⏱ Optimise require order so config is first
- the first require to config will cause the files to be read etc
- this ensures that it happens early, and isn't confusingly timed as part of loading a different module
* 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
|
|
|
ghostBookshelf = require('./base'),
|
2017-12-12 00:47:46 +03:00
|
|
|
common = require('../lib/common'),
|
|
|
|
validation = require('../data/validation'),
|
2018-04-06 19:19:45 +03:00
|
|
|
internalContext = {context: {internal: true}};
|
🎨 ⏱ Cleanup / optimise the server.init() function (#7985)
refs #2182
* 🔥 Remove unused options from server init
- this is left over from old code and is now unused
* 🎨 Move knex-migrator check to db health
- Move complex check function into own module
- Call module from server/index.js
- This just improves the readability of server/index.js
* 🔥 Remove old comments
- These comments all make no sense now!
* 🎨 ⏱ Move model init out of promise chain
- Model.init() does not return a promise
- Therefore, we can move it to the top of the init function, outside of the promise change
- This should be a minor optimisation, and again improves readability /clarity of what's happening
* ✨ ⁉️ Move DBHash init / first run to Settings model
- this structure is left over from when we had code we executed on the first run of Ghost
- the implementation used the API to initialise one setting before populateDefaults is called
- this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work
- the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults()
- it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!)
- perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁
* ⏱ Optimise require order so config is first
- the first require to config will cause the files to be read etc
- this ensures that it happens early, and isn't confusingly timed as part of loading a different module
* 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
let Settings, defaultSettings;
|
2013-09-02 05:49:08 +04:00
|
|
|
|
|
|
|
// For neatness, the defaults file is split into categories.
|
|
|
|
// It's much easier for us to work with it as a single level
|
|
|
|
// instead of iterating those categories every time
|
|
|
|
function parseDefaultSettings() {
|
2016-01-25 20:50:04 +03:00
|
|
|
var defaultSettingsInCategories = require('../data/schema/').defaultSettings,
|
🎨 ⏱ Cleanup / optimise the server.init() function (#7985)
refs #2182
* 🔥 Remove unused options from server init
- this is left over from old code and is now unused
* 🎨 Move knex-migrator check to db health
- Move complex check function into own module
- Call module from server/index.js
- This just improves the readability of server/index.js
* 🔥 Remove old comments
- These comments all make no sense now!
* 🎨 ⏱ Move model init out of promise chain
- Model.init() does not return a promise
- Therefore, we can move it to the top of the init function, outside of the promise change
- This should be a minor optimisation, and again improves readability /clarity of what's happening
* ✨ ⁉️ Move DBHash init / first run to Settings model
- this structure is left over from when we had code we executed on the first run of Ghost
- the implementation used the API to initialise one setting before populateDefaults is called
- this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work
- the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults()
- it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!)
- perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁
* ⏱ Optimise require order so config is first
- the first require to config will cause the files to be read etc
- this ensures that it happens early, and isn't confusingly timed as part of loading a different module
* 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
|
|
|
defaultSettingsFlattened = {},
|
|
|
|
dynamicDefault = {
|
2017-10-05 13:07:32 +03:00
|
|
|
db_hash: uuid.v4(),
|
|
|
|
public_hash: crypto.randomBytes(15).toString('hex')
|
🎨 ⏱ Cleanup / optimise the server.init() function (#7985)
refs #2182
* 🔥 Remove unused options from server init
- this is left over from old code and is now unused
* 🎨 Move knex-migrator check to db health
- Move complex check function into own module
- Call module from server/index.js
- This just improves the readability of server/index.js
* 🔥 Remove old comments
- These comments all make no sense now!
* 🎨 ⏱ Move model init out of promise chain
- Model.init() does not return a promise
- Therefore, we can move it to the top of the init function, outside of the promise change
- This should be a minor optimisation, and again improves readability /clarity of what's happening
* ✨ ⁉️ Move DBHash init / first run to Settings model
- this structure is left over from when we had code we executed on the first run of Ghost
- the implementation used the API to initialise one setting before populateDefaults is called
- this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work
- the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults()
- it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!)
- perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁
* ⏱ Optimise require order so config is first
- the first require to config will cause the files to be read etc
- this ensures that it happens early, and isn't confusingly timed as part of loading a different module
* 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
|
|
|
};
|
2013-09-02 05:49:08 +04:00
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
_.each(defaultSettingsInCategories, function each(settings, categoryName) {
|
|
|
|
_.each(settings, function each(setting, settingName) {
|
2013-09-02 05:49:08 +04:00
|
|
|
setting.type = categoryName;
|
|
|
|
setting.key = settingName;
|
🎨 ⏱ Cleanup / optimise the server.init() function (#7985)
refs #2182
* 🔥 Remove unused options from server init
- this is left over from old code and is now unused
* 🎨 Move knex-migrator check to db health
- Move complex check function into own module
- Call module from server/index.js
- This just improves the readability of server/index.js
* 🔥 Remove old comments
- These comments all make no sense now!
* 🎨 ⏱ Move model init out of promise chain
- Model.init() does not return a promise
- Therefore, we can move it to the top of the init function, outside of the promise change
- This should be a minor optimisation, and again improves readability /clarity of what's happening
* ✨ ⁉️ Move DBHash init / first run to Settings model
- this structure is left over from when we had code we executed on the first run of Ghost
- the implementation used the API to initialise one setting before populateDefaults is called
- this had lots of dependencies - the whole model, API, and permissions structure had to be initialised for it to work
- the new implementation is simpler, it captures the dbHash getting initialised during populateDefaults()
- it also adds an event, so we can do first-run code later if we really want to (or maybe apps can?!)
- perhaps this is hiding behaviour, and there's a nicer way to do it, but populateDefaults seems like a sane place to populate a default setting 😁
* ⏱ Optimise require order so config is first
- the first require to config will cause the files to be read etc
- this ensures that it happens early, and isn't confusingly timed as part of loading a different module
* 🎨 Simplify settings model changes
2017-02-17 19:44:34 +03:00
|
|
|
if (dynamicDefault[setting.key]) {
|
|
|
|
setting.defaultValue = dynamicDefault[setting.key];
|
|
|
|
}
|
2014-07-28 01:04:58 +04:00
|
|
|
|
2013-09-02 05:49:08 +04:00
|
|
|
defaultSettingsFlattened[settingName] = setting;
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
|
|
|
return defaultSettingsFlattened;
|
|
|
|
}
|
2014-06-17 19:36:47 +04:00
|
|
|
|
|
|
|
function getDefaultSettings() {
|
|
|
|
if (!defaultSettings) {
|
|
|
|
defaultSettings = parseDefaultSettings();
|
|
|
|
}
|
|
|
|
|
|
|
|
return defaultSettings;
|
|
|
|
}
|
2013-06-08 09:03:55 +04:00
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
// Each setting is saved as a separate row in the database,
|
|
|
|
// but the overlying API treats them as a single key:value mapping
|
2013-09-23 02:20:08 +04:00
|
|
|
Settings = ghostBookshelf.Model.extend({
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
tableName: 'settings',
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
defaults: function defaults() {
|
2013-06-25 15:43:15 +04:00
|
|
|
return {
|
2013-09-14 22:04:41 +04:00
|
|
|
type: 'core'
|
2013-06-25 15:43:15 +04:00
|
|
|
};
|
2013-08-25 14:49:31 +04:00
|
|
|
},
|
|
|
|
|
2017-07-21 11:58:58 +03:00
|
|
|
emitChange: function emitChange(event, options) {
|
2018-04-06 19:19:45 +03:00
|
|
|
const eventToTrigger = 'settings' + '.' + event;
|
|
|
|
ghostBookshelf.Model.prototype.emitChange.bind(this)(this, eventToTrigger, options);
|
2015-06-15 11:36:01 +03:00
|
|
|
},
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onDestroyed: function onDestroyed(model, options) {
|
|
|
|
model.emitChange('deleted', options);
|
|
|
|
model.emitChange(model._previousAttributes.key + '.' + 'deleted', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
},
|
2015-06-15 11:36:01 +03:00
|
|
|
|
2017-07-21 11:58:58 +03:00
|
|
|
onCreated: function onCreated(model, response, options) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('added', options);
|
2017-07-21 11:58:58 +03:00
|
|
|
model.emitChange(model.attributes.key + '.' + 'added', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
},
|
|
|
|
|
2017-07-21 11:58:58 +03:00
|
|
|
onUpdated: function onUpdated(model, response, options) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('edited', options);
|
2017-07-21 11:58:58 +03:00
|
|
|
model.emitChange(model.attributes.key + '.' + 'edited', options);
|
2015-06-15 11:36:01 +03:00
|
|
|
},
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
onValidate: function onValidate() {
|
2018-02-16 02:49:15 +03:00
|
|
|
var self = this;
|
2014-07-10 02:11:04 +04:00
|
|
|
|
2018-02-16 02:49:15 +03:00
|
|
|
return ghostBookshelf.Model.prototype.onValidate.apply(this, arguments)
|
|
|
|
.then(function then() {
|
|
|
|
return validation.validateSettings(getDefaultSettings(), self);
|
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
}, {
|
2016-06-03 11:06:18 +03:00
|
|
|
findOne: function (data, options) {
|
|
|
|
if (_.isEmpty(data)) {
|
|
|
|
options = data;
|
|
|
|
}
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
// Allow for just passing the key instead of attributes
|
2016-06-03 11:06:18 +03:00
|
|
|
if (!_.isObject(data)) {
|
|
|
|
data = {key: data};
|
2013-06-15 18:10:30 +04:00
|
|
|
}
|
2016-06-03 11:06:18 +03:00
|
|
|
|
|
|
|
return Promise.resolve(ghostBookshelf.Model.findOne.call(this, data, options));
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
2013-06-08 09:03:55 +04:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
edit: function (data, unfilteredOptions) {
|
|
|
|
var options = this.filterOptions(unfilteredOptions, 'edit'),
|
|
|
|
self = this;
|
2014-04-03 17:03:09 +04:00
|
|
|
|
Refactor API arguments
closes #2610, refs #2697
- cleanup API index.js, and add docs
- all API methods take consistent arguments: object & options
- browse, read, destroy take options, edit and add take object and options
- the context is passed as part of options, meaning no more .call
everywhere
- destroy expects an object, rather than an id all the way down to the model layer
- route params such as :id, :slug, and :key are passed as an option & used
to perform reads, updates and deletes where possible - settings / themes
may need work here still
- HTTP posts api can find a post by slug
- Add API utils for checkData
2014-05-08 16:41:19 +04:00
|
|
|
if (!Array.isArray(data)) {
|
|
|
|
data = [data];
|
2013-06-08 09:03:55 +04:00
|
|
|
}
|
2014-04-03 17:03:09 +04:00
|
|
|
|
2014-08-17 10:17:23 +04:00
|
|
|
return Promise.map(data, function (item) {
|
2013-06-25 15:43:15 +04:00
|
|
|
// Accept an array of models as input
|
2017-12-12 00:47:46 +03:00
|
|
|
if (item.toJSON) {
|
|
|
|
item = item.toJSON();
|
|
|
|
}
|
2014-04-28 03:28:50 +04:00
|
|
|
if (!(_.isString(item.key) && item.key.length > 0)) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.models.settings.valueCannotBeBlank')}));
|
2014-04-28 03:28:50 +04:00
|
|
|
}
|
2014-05-06 05:45:08 +04:00
|
|
|
|
|
|
|
item = self.filterData(item);
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
return Settings.forge({key: item.key}).fetch(options).then(function then(setting) {
|
2013-09-02 05:49:08 +04:00
|
|
|
if (setting) {
|
2016-06-03 11:06:18 +03:00
|
|
|
// it's allowed to edit all attributes in case of importing/migrating
|
|
|
|
if (options.importing) {
|
2017-10-31 18:47:30 +03:00
|
|
|
return setting.save(item, options);
|
|
|
|
} else {
|
|
|
|
// If we have a value, set it.
|
|
|
|
if (item.hasOwnProperty('value')) {
|
|
|
|
setting.set('value', item.value);
|
|
|
|
}
|
|
|
|
// Internal context can overwrite type (for fixture migrations)
|
|
|
|
if (options.context && options.context.internal && item.hasOwnProperty('type')) {
|
|
|
|
setting.set('type', item.type);
|
|
|
|
}
|
|
|
|
|
|
|
|
// If anything has changed, save the updated model
|
|
|
|
if (setting.hasChanged()) {
|
|
|
|
return setting.save(null, options);
|
|
|
|
}
|
|
|
|
|
|
|
|
return setting;
|
2016-06-03 11:06:18 +03:00
|
|
|
}
|
2013-09-02 05:49:08 +04:00
|
|
|
}
|
2014-04-03 17:03:09 +04:00
|
|
|
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.models.settings.unableToFindSetting', {key: item.key})}));
|
2016-10-04 18:33:43 +03:00
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
});
|
2013-09-02 05:49:08 +04:00
|
|
|
},
|
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
populateDefaults: function populateDefaults(unfilteredOptions) {
|
|
|
|
var options = this.filterOptions(unfilteredOptions, 'populateDefaults'),
|
|
|
|
self = this;
|
2017-03-03 01:00:01 +03:00
|
|
|
|
Sorted out the mixed usages of `include` and `withRelated` (#9425)
no issue
- this commit cleans up the usages of `include` and `withRelated`.
### API layer (`include`)
- as request parameter e.g. `?include=roles,tags`
- as theme API parameter e.g. `{{get .... include="author"}}`
- as internal API access e.g. `api.posts.browse({include: 'author,tags'})`
- the `include` notation is more readable than `withRelated`
- and it allows us to use a different easier format (comma separated list)
- the API utility transforms these more readable properties into model style (or into Ghost style)
### Model access (`withRelated`)
- e.g. `models.Post.findPage({withRelated: ['tags']})`
- driven by bookshelf
---
Commits explained.
* Reorder the usage of `convertOptions`
- 1. validation
- 2. options convertion
- 3. permissions
- the reason is simple, the permission layer access the model layer
- we have to prepare the options before talking to the model layer
- added `convertOptions` where it was missed (not required, but for consistency reasons)
* Use `withRelated` when accessing the model layer and use `include` when accessing the API layer
* Change `convertOptions` API utiliy
- API Usage
- ghost.api(..., {include: 'tags,authors'})
- `include` should only be used when calling the API (either via request or via manual usage)
- `include` is only for readability and easier format
- Ghost (Model Layer Usage)
- models.Post.findOne(..., {withRelated: ['tags', 'authors']})
- should only use `withRelated`
- model layer cannot read 'tags,authors`
- model layer has no idea what `include` means, speaks a different language
- `withRelated` is bookshelf
- internal usage
* include-count plugin: use `withRelated` instead of `include`
- imagine you outsource this plugin to git and publish it to npm
- `include` is an unknown option in bookshelf
* Updated `permittedOptions` in base model
- `include` is no longer a known option
* Remove all occurances of `include` in the model layer
* Extend `filterOptions` base function
- this function should be called as first action
- we clone the unfiltered options
- check if you are using `include` (this is a protection which could help us in the beginning)
- check for permitted and (later on default `withRelated`) options
- the usage is coming in next commit
* Ensure we call `filterOptions` as first action
- use `ghostBookshelf.Model.filterOptions` as first action
- consistent naming pattern for incoming options: `unfilteredOptions`
- re-added allowed options for `toJSON`
- one unsolved architecture problem:
- if you override a function e.g. `edit`
- then you should call `filterOptions` as first action
- the base implementation of e.g. `edit` will call it again
- future improvement
* Removed `findOne` from Invite model
- no longer needed, the base implementation is the same
2018-02-15 12:53:53 +03:00
|
|
|
if (!options.context) {
|
|
|
|
options.context = internalContext.context;
|
|
|
|
}
|
2016-07-14 13:59:42 +03:00
|
|
|
|
2017-03-03 01:00:01 +03:00
|
|
|
return this
|
|
|
|
.findAll(options)
|
|
|
|
.then(function checkAllSettings(allSettings) {
|
2017-12-12 00:47:46 +03:00
|
|
|
var usedKeys = allSettings.models.map(function mapper(setting) {
|
|
|
|
return setting.get('key');
|
|
|
|
}),
|
2017-03-03 01:00:01 +03:00
|
|
|
insertOperations = [];
|
2016-07-14 13:59:42 +03:00
|
|
|
|
2017-03-03 01:00:01 +03:00
|
|
|
_.each(getDefaultSettings(), function forEachDefault(defaultSetting, defaultSettingKey) {
|
|
|
|
var isMissingFromDB = usedKeys.indexOf(defaultSettingKey) === -1;
|
|
|
|
if (isMissingFromDB) {
|
|
|
|
defaultSetting.value = defaultSetting.defaultValue;
|
|
|
|
insertOperations.push(Settings.forge(defaultSetting).save(null, options));
|
|
|
|
}
|
|
|
|
});
|
2013-09-02 05:49:08 +04:00
|
|
|
|
2017-03-03 01:00:01 +03:00
|
|
|
if (insertOperations.length > 0) {
|
|
|
|
return Promise.all(insertOperations).then(function fetchAllToReturn() {
|
|
|
|
return self.findAll(options);
|
|
|
|
});
|
2013-09-02 05:49:08 +04:00
|
|
|
}
|
|
|
|
|
2017-03-03 01:00:01 +03:00
|
|
|
return allSettings;
|
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
});
|
2013-06-08 09:03:55 +04:00
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
module.exports = {
|
2014-07-13 15:17:18 +04:00
|
|
|
Settings: ghostBookshelf.model('Settings', Settings)
|
2013-09-02 05:49:08 +04:00
|
|
|
};
|