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
|
|
|
// # Posts API
|
2014-06-03 17:05:25 +04:00
|
|
|
// RESTful API for the Post resource
|
2017-09-12 18:31:14 +03:00
|
|
|
var Promise = require('bluebird'),
|
|
|
|
_ = require('lodash'),
|
2017-12-14 00:20:02 +03:00
|
|
|
pipeline = require('../lib/promise/pipeline'),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils = require('./utils'),
|
2017-09-12 18:31:14 +03:00
|
|
|
models = require('../models'),
|
2017-12-12 00:47:46 +03:00
|
|
|
common = require('../lib/common'),
|
2017-09-12 18:31:14 +03:00
|
|
|
docName = 'posts',
|
2015-08-09 22:30:04 +03:00
|
|
|
allowedIncludes = [
|
2017-10-13 17:44:39 +03:00
|
|
|
'created_by', 'updated_by', 'published_by', 'author', 'tags', 'fields'
|
2015-08-09 22:30:04 +03:00
|
|
|
],
|
2018-02-07 12:46:22 +03:00
|
|
|
unsafeAttrs = ['author_id', 'status'],
|
2014-05-09 14:11:29 +04:00
|
|
|
posts;
|
2013-12-06 12:51:35 +04:00
|
|
|
|
2014-06-03 17:05:25 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ### Posts API Methods
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
2017-12-14 16:13:40 +03:00
|
|
|
* **See:** [API Methods](constants.js.html#api%20methods)
|
2014-06-03 17:05:25 +04:00
|
|
|
*/
|
2015-07-01 21:17:56 +03:00
|
|
|
|
2013-12-06 12:51:35 +04:00
|
|
|
posts = {
|
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
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Browse
|
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
|
|
|
* Find a paginated set of posts
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
|
|
|
* Will only return published posts unless we have an authenticated user and an alternative status
|
|
|
|
* parameter.
|
|
|
|
*
|
|
|
|
* Will return without static pages unless told otherwise
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* @public
|
2015-05-06 02:06:43 +03:00
|
|
|
* @param {{context, page, limit, status, staticPages, tag, featured}} options (optional)
|
2015-06-22 23:11:35 +03:00
|
|
|
* @returns {Promise<Posts>} Posts Collection with Meta
|
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
|
|
|
*/
|
2013-12-06 12:51:35 +04:00
|
|
|
browse: function browse(options) {
|
2017-05-30 13:40:39 +03:00
|
|
|
var extraOptions = ['status', 'formats'],
|
2015-11-04 12:03:03 +03:00
|
|
|
permittedOptions,
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks;
|
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
|
|
|
|
2015-11-04 12:03:03 +03:00
|
|
|
// Workaround to remove static pages from results
|
|
|
|
// TODO: rework after https://github.com/TryGhost/Ghost/issues/5151
|
|
|
|
if (options && options.context && (options.context.user || options.context.internal)) {
|
|
|
|
extraOptions.push('staticPages');
|
|
|
|
}
|
2017-12-14 00:14:19 +03:00
|
|
|
permittedOptions = localUtils.browseDefaultOptions.concat(extraOptions);
|
2015-11-04 12:03:03 +03:00
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function modelQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Post.findPage(options);
|
2014-04-27 20:58:34 +04:00
|
|
|
}
|
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: permittedOptions}),
|
|
|
|
localUtils.convertOptions(allowedIncludes, models.Post.allowedFormats),
|
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.handlePublicPermissions(docName, 'browse', unsafeAttrs),
|
2015-07-01 21:17:56 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
|
|
|
return pipeline(tasks, options);
|
2013-12-06 12:51:35 +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
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Read
|
2015-04-16 22:40:32 +03:00
|
|
|
* Find a post, by ID, UUID, or Slug
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
|
|
|
* @public
|
2015-06-22 23:11:35 +03:00
|
|
|
* @param {Object} options
|
|
|
|
* @return {Promise<Post>} Post
|
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
|
|
|
*/
|
2014-04-08 17:40:33 +04:00
|
|
|
read: function read(options) {
|
2017-09-28 15:38:32 +03:00
|
|
|
var attrs = ['id', 'slug', 'status', 'uuid'],
|
|
|
|
// NOTE: the scheduler API uses the post API and forwards custom options
|
|
|
|
extraAllowedOptions = options.opts || ['formats'],
|
2015-06-22 23:11:35 +03:00
|
|
|
tasks;
|
2014-04-19 19:03:20 +04:00
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function modelQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Post.findOne(options.data, _.omit(options, ['data']))
|
|
|
|
.then(function onModelResponse(model) {
|
|
|
|
if (!model) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.posts.postNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
posts: [model.toJSON(options)]
|
|
|
|
};
|
|
|
|
});
|
2014-04-27 20:58:34 +04:00
|
|
|
}
|
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {attrs: attrs, opts: extraAllowedOptions}),
|
|
|
|
localUtils.convertOptions(allowedIncludes, models.Post.allowedFormats),
|
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.handlePublicPermissions(docName, 'read', unsafeAttrs),
|
2015-07-01 21:17:56 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
// 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);
|
2013-12-06 12:51:35 +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
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Edit
|
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
|
|
|
* Update properties of a post
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
|
|
|
* @public
|
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
|
|
|
* @param {Post} object Post or specific properties to update
|
|
|
|
* @param {{id (required), context, include,...}} options
|
|
|
|
* @return {Promise(Post)} Edited Post
|
|
|
|
*/
|
|
|
|
edit: function edit(object, options) {
|
2017-09-28 15:38:32 +03:00
|
|
|
var tasks,
|
|
|
|
// NOTE: the scheduler API uses the post API and forwards custom options
|
|
|
|
extraAllowedOptions = options.opts || [];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function modelQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Post.edit(options.data.posts[0], _.omit(options, ['data']))
|
|
|
|
.then(function onModelResponse(model) {
|
|
|
|
if (!model) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.posts.postNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
var post = model.toJSON(options);
|
|
|
|
|
|
|
|
// If previously was not published and now is (or vice versa), signal the change
|
|
|
|
// @TODO: `statusChanged` get's added for the API headers only. Reconsider this.
|
|
|
|
post.statusChanged = false;
|
|
|
|
if (model.updated('status') !== model.get('status')) {
|
|
|
|
post.statusChanged = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
posts: [post]
|
|
|
|
};
|
|
|
|
});
|
2015-06-22 23:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: localUtils.idDefaultOptions.concat(extraAllowedOptions)}),
|
|
|
|
localUtils.convertOptions(allowedIncludes),
|
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.handlePermissions(docName, 'edit', unsafeAttrs),
|
2015-07-01 21:17:56 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
// 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);
|
2013-12-06 12:51:35 +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
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Add
|
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
|
|
|
* Create a new post along with any tags
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
|
|
|
* @public
|
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
|
|
|
* @param {Post} object
|
|
|
|
* @param {{context, include,...}} options
|
|
|
|
* @return {Promise(Post)} Created Post
|
|
|
|
*/
|
|
|
|
add: function add(object, options) {
|
2015-06-22 23:11:35 +03:00
|
|
|
var tasks;
|
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
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
/**
|
|
|
|
* ### Model Query
|
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function modelQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Post.add(options.data.posts[0], _.omit(options, ['data']))
|
|
|
|
.then(function onModelResponse(model) {
|
|
|
|
var post = model.toJSON(options);
|
|
|
|
|
|
|
|
if (post.status === 'published') {
|
|
|
|
// When creating a new post that is published right now, signal the change
|
|
|
|
post.statusChanged = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return {posts: [post]};
|
|
|
|
});
|
2015-06-22 23:11:35 +03:00
|
|
|
}
|
2014-05-06 14:14:58 +04:00
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName),
|
|
|
|
localUtils.convertOptions(allowedIncludes),
|
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.handlePermissions(docName, 'add', unsafeAttrs),
|
2015-07-01 21:17:56 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
// 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);
|
2013-12-06 12:51:35 +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
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Destroy
|
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
|
|
|
* Delete a post, cleans up tag relations, but not unused tags
|
2014-06-03 17:05:25 +04:00
|
|
|
*
|
|
|
|
* @public
|
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
|
|
|
* @param {{id (required), context,...}} options
|
2016-03-20 20:26:42 +03:00
|
|
|
* @return {Promise}
|
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
|
|
|
*/
|
|
|
|
destroy: function destroy(options) {
|
2015-06-22 23:11:35 +03:00
|
|
|
var tasks;
|
2014-04-22 05:04:30 +04:00
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
/**
|
2016-03-02 07:42:01 +03:00
|
|
|
* @function deletePost
|
|
|
|
* @param {Object} options
|
2015-06-22 23:11:35 +03:00
|
|
|
*/
|
2016-03-02 07:42:01 +03:00
|
|
|
function deletePost(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
var Post = models.Post,
|
2016-03-02 07:42:01 +03:00
|
|
|
data = _.defaults({status: 'all'}, options),
|
2016-03-20 20:26:42 +03:00
|
|
|
fetchOpts = _.defaults({require: true, columns: 'id'}, options);
|
2016-03-02 07:42:01 +03:00
|
|
|
|
2016-08-25 08:13:08 +03:00
|
|
|
return Post.findOne(data, fetchOpts).then(function () {
|
|
|
|
return Post.destroy(options).return(null);
|
2016-03-02 07:42:01 +03:00
|
|
|
}).catch(Post.NotFoundError, function () {
|
2018-02-21 18:59:48 +03:00
|
|
|
throw new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.api.posts.postNotFound')
|
|
|
|
});
|
2013-12-06 12:51:35 +04:00
|
|
|
});
|
2015-06-22 23:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Push all of our tasks into a `tasks` array in the correct order
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: localUtils.idDefaultOptions}),
|
|
|
|
localUtils.convertOptions(allowedIncludes),
|
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.handlePermissions(docName, 'destroy', unsafeAttrs),
|
2016-03-02 07:42:01 +03:00
|
|
|
deletePost
|
2015-07-01 21:17:56 +03:00
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
// Pipeline calls each task passing the result of one to be the arguments for the next
|
2016-03-20 20:26:42 +03:00
|
|
|
return pipeline(tasks, options);
|
2013-12-06 12:51:35 +04:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-09-10 08:06:24 +04:00
|
|
|
module.exports = posts;
|