2016-04-14 23:44:05 +03:00
|
|
|
// # Tag API
|
|
|
|
// RESTful API for the Tag resource
|
2018-09-18 16:59:56 +03:00
|
|
|
const Promise = require('bluebird'),
|
2017-09-12 18:31:14 +03:00
|
|
|
_ = require('lodash'),
|
2017-12-13 21:15:29 +03:00
|
|
|
fs = require('fs-extra'),
|
2018-09-27 17:06:57 +03:00
|
|
|
pipeline = require('../../lib/promise/pipeline'),
|
|
|
|
fsLib = require('../../lib/fs'),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils = require('./utils'),
|
2018-09-27 17:06:57 +03:00
|
|
|
models = require('../../models'),
|
|
|
|
common = require('../../lib/common'),
|
2018-09-18 16:59:56 +03:00
|
|
|
docName = 'subscribers';
|
|
|
|
|
|
|
|
let subscribers;
|
2016-04-14 23:44:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Subscribers API Methods
|
|
|
|
*
|
2017-12-14 16:13:40 +03:00
|
|
|
* **See:** [API Methods](constants.js.html#api%20methods)
|
2016-04-14 23:44:05 +03:00
|
|
|
*/
|
|
|
|
subscribers = {
|
|
|
|
/**
|
|
|
|
* ## Browse
|
|
|
|
* @param {{context}} options
|
|
|
|
* @returns {Promise<Subscriber>} Subscriber Collection
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
browse(options) {
|
|
|
|
let tasks;
|
2016-04-14 23:44:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
2018-09-26 15:11:22 +03:00
|
|
|
return models.Subscriber.findPage(options)
|
|
|
|
.then(({data, meta}) => {
|
|
|
|
return {
|
|
|
|
subscribers: data.map(model => model.toJSON(options)),
|
|
|
|
meta: meta
|
|
|
|
};
|
|
|
|
});
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: localUtils.browseDefaultOptions}),
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'browse'),
|
2016-04-14 23:44:05 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Read
|
|
|
|
* @param {{id}} options
|
|
|
|
* @return {Promise<Subscriber>} Subscriber
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
read(options) {
|
|
|
|
let attrs = ['id', 'email'],
|
2016-04-14 23:44:05 +03:00
|
|
|
tasks;
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Subscriber.findOne(options.data, _.omit(options, ['data']))
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((model) => {
|
2017-09-27 11:31:41 +03:00
|
|
|
if (!model) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.subscribers.subscriberNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
subscribers: [model.toJSON(options)]
|
|
|
|
};
|
|
|
|
});
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {attrs: attrs}),
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'read'),
|
2016-04-14 23:44:05 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
2017-09-27 11:31:41 +03:00
|
|
|
return pipeline(tasks, options);
|
2016-04-14 23:44:05 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Add
|
|
|
|
* @param {Subscriber} object the subscriber to create
|
|
|
|
* @returns {Promise(Subscriber)} Newly created Subscriber
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
add(object, options) {
|
|
|
|
let tasks;
|
2016-04-14 23:44:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Subscriber.getByEmail(options.data.subscribers[0].email)
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((subscriber) => {
|
2016-05-08 17:49:12 +03:00
|
|
|
if (subscriber && options.context.external) {
|
|
|
|
// we don't expose this information
|
|
|
|
return Promise.resolve(subscriber);
|
|
|
|
} else if (subscriber) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.subscribers.subscriberAlreadyExists')}));
|
2016-05-08 17:49:12 +03:00
|
|
|
}
|
|
|
|
|
2018-09-18 16:59:56 +03:00
|
|
|
return models.Subscriber.add(options.data.subscribers[0], _.omit(options, ['data'])).catch((error) => {
|
2016-05-08 17:49:12 +03:00
|
|
|
if (error.code && error.message.toLowerCase().indexOf('unique') !== -1) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.subscribers.subscriberAlreadyExists')}));
|
2016-05-08 17:49:12 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.reject(error);
|
|
|
|
});
|
2017-09-27 11:31:41 +03:00
|
|
|
})
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((model) => {
|
2017-09-27 11:31:41 +03:00
|
|
|
return {
|
|
|
|
subscribers: [model.toJSON(options)]
|
|
|
|
};
|
2016-05-08 17:49:12 +03:00
|
|
|
});
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName),
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'add'),
|
2016-04-14 23:44:05 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
2017-09-27 11:31:41 +03:00
|
|
|
return pipeline(tasks, object, options);
|
2016-04-14 23:44:05 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Edit
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
* @param {Subscriber} object Subscriber or specific properties to update
|
|
|
|
* @param {{id, context, include}} options
|
|
|
|
* @return {Promise<Subscriber>} Edited Subscriber
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
edit(object, options) {
|
|
|
|
let tasks;
|
2016-04-14 23:44:05 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Subscriber.edit(options.data.subscribers[0], _.omit(options, ['data']))
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((model) => {
|
2017-09-27 11:31:41 +03:00
|
|
|
if (!model) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.subscribers.subscriberNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
subscribers: [model.toJSON(options)]
|
|
|
|
};
|
|
|
|
});
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: localUtils.idDefaultOptions}),
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'edit'),
|
2016-04-14 23:44:05 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
2017-09-27 11:31:41 +03:00
|
|
|
return pipeline(tasks, object, options);
|
2016-04-14 23:44:05 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ## Destroy
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
* @param {{id, context}} options
|
|
|
|
* @return {Promise}
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
destroy(options) {
|
|
|
|
let tasks;
|
2016-04-14 23:44:05 +03:00
|
|
|
|
2017-11-14 14:09:41 +03:00
|
|
|
/**
|
|
|
|
* ### Delete Subscriber
|
|
|
|
* If we have an email param, check the subscriber exists
|
|
|
|
* @type {[type]}
|
|
|
|
*/
|
|
|
|
function getSubscriberByEmail(options) {
|
|
|
|
if (options.email) {
|
|
|
|
return models.Subscriber.getByEmail(options.email, options)
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((subscriber) => {
|
2017-11-14 14:09:41 +03:00
|
|
|
if (!subscriber) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.subscribers.subscriberNotFound')
|
2017-11-14 14:09:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
options.id = subscriber.get('id');
|
|
|
|
return options;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
2016-04-14 23:44:05 +03:00
|
|
|
/**
|
|
|
|
* ### Delete Subscriber
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
*/
|
|
|
|
function doQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Subscriber.destroy(options).return(null);
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: ['id', 'email']}),
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'destroy'),
|
2017-11-14 14:09:41 +03:00
|
|
|
getSubscriberByEmail,
|
2016-04-14 23:44:05 +03:00
|
|
|
doQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Export Subscribers
|
|
|
|
* Generate the CSV to export
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
* @param {{context}} options
|
|
|
|
* @returns {Promise} Ghost Export CSV format
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
exportCSV(options) {
|
|
|
|
let tasks = [];
|
2016-04-14 23:44:05 +03:00
|
|
|
|
|
|
|
options = options || {};
|
|
|
|
|
|
|
|
function formatCSV(data) {
|
2018-09-18 16:59:56 +03:00
|
|
|
let fields = ['id', 'email', 'created_at', 'deleted_at'],
|
|
|
|
csv = `${fields.join(',')}\r\n`,
|
2016-04-14 23:44:05 +03:00
|
|
|
subscriber,
|
|
|
|
field,
|
|
|
|
j,
|
|
|
|
i;
|
|
|
|
|
|
|
|
for (j = 0; j < data.length; j = j + 1) {
|
|
|
|
subscriber = data[j];
|
|
|
|
|
|
|
|
for (i = 0; i < fields.length; i = i + 1) {
|
|
|
|
field = fields[i];
|
|
|
|
csv += subscriber[field] !== null ? subscriber[field] : '';
|
|
|
|
if (i !== fields.length - 1) {
|
|
|
|
csv += ',';
|
|
|
|
}
|
|
|
|
}
|
|
|
|
csv += '\r\n';
|
|
|
|
}
|
|
|
|
return csv;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Export data, otherwise send error 500
|
|
|
|
function exportSubscribers() {
|
2018-09-18 16:59:56 +03:00
|
|
|
return models.Subscriber.findAll(options).then((data) => {
|
2017-02-08 13:37:09 +03:00
|
|
|
return formatCSV(data.toJSON(options));
|
2018-09-18 16:59:56 +03:00
|
|
|
}).catch((err) => {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.GhostError({err: err}));
|
2016-04-14 23:44:05 +03:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
tasks = [
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'browse'),
|
2016-04-14 23:44:05 +03:00
|
|
|
exportSubscribers
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Import CSV
|
|
|
|
* Import subscribers from a CSV file
|
|
|
|
*
|
|
|
|
* @public
|
|
|
|
* @param {{context}} options
|
|
|
|
* @returns {Promise} Success
|
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
importCSV(options) {
|
|
|
|
let tasks = [];
|
2016-04-14 23:44:05 +03:00
|
|
|
options = options || {};
|
|
|
|
|
|
|
|
function importCSV(options) {
|
2018-09-18 16:59:56 +03:00
|
|
|
let filePath = options.path,
|
2016-05-08 10:12:37 +03:00
|
|
|
fulfilled = 0,
|
|
|
|
invalid = 0,
|
|
|
|
duplicates = 0;
|
|
|
|
|
2017-12-15 00:07:53 +03:00
|
|
|
return fsLib.readCSV({
|
2016-05-08 10:12:37 +03:00
|
|
|
path: filePath,
|
2016-06-03 14:35:17 +03:00
|
|
|
columnsToExtract: [{name: 'email', lookup: /email/i}]
|
2018-09-18 16:59:56 +03:00
|
|
|
}).then((result) => {
|
|
|
|
return Promise.all(result.map((entry) => {
|
2016-05-08 10:12:37 +03:00
|
|
|
return subscribers.add(
|
|
|
|
{subscribers: [{email: entry.email}]},
|
|
|
|
{context: options.context}
|
|
|
|
).reflect();
|
2018-09-18 16:59:56 +03:00
|
|
|
})).each((inspection) => {
|
2016-05-08 10:12:37 +03:00
|
|
|
if (inspection.isFulfilled()) {
|
|
|
|
fulfilled = fulfilled + 1;
|
|
|
|
} else {
|
2017-12-12 00:47:46 +03:00
|
|
|
if (inspection.reason() instanceof common.errors.ValidationError) {
|
2016-05-08 10:12:37 +03:00
|
|
|
duplicates = duplicates + 1;
|
2016-04-21 18:37:52 +03:00
|
|
|
} else {
|
2016-05-08 10:12:37 +03:00
|
|
|
invalid = invalid + 1;
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
2018-09-18 16:59:56 +03:00
|
|
|
}).then(() => {
|
2016-05-08 10:12:37 +03:00
|
|
|
return {
|
|
|
|
meta: {
|
|
|
|
stats: {
|
|
|
|
imported: fulfilled,
|
|
|
|
duplicates: duplicates,
|
|
|
|
invalid: invalid
|
2016-04-14 23:44:05 +03:00
|
|
|
}
|
2016-05-08 10:12:37 +03:00
|
|
|
}
|
|
|
|
};
|
2018-09-18 16:59:56 +03:00
|
|
|
}).finally(() => {
|
2016-05-08 10:12:37 +03:00
|
|
|
// Remove uploaded file from tmp location
|
2017-12-13 22:03:07 +03:00
|
|
|
return fs.unlink(filePath);
|
2016-04-14 23:44:05 +03:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
tasks = [
|
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
|
|
|
localUtils.convertOptions(),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.handlePermissions(docName, 'add'),
|
2016-04-14 23:44:05 +03:00
|
|
|
importCSV
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
module.exports = subscribers;
|