2014-06-03 17:05:25 +04:00
|
|
|
// # Users API
|
|
|
|
// RESTful API for the User resource
|
2018-09-18 16:59:56 +03:00
|
|
|
const Promise = require('bluebird'),
|
2017-09-12 18:31:14 +03:00
|
|
|
_ = require('lodash'),
|
2018-09-27 17:06:57 +03:00
|
|
|
pipeline = require('../../lib/promise/pipeline'),
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils = require('./utils'),
|
2018-09-27 17:06:57 +03:00
|
|
|
canThis = require('../../services/permissions').canThis,
|
|
|
|
models = require('../../models'),
|
|
|
|
common = require('../../lib/common'),
|
2018-10-03 16:44:30 +03:00
|
|
|
{urlsForUser} = require('./decorators/urls'),
|
2017-09-12 18:31:14 +03:00
|
|
|
docName = 'users',
|
2018-09-18 16:59:56 +03:00
|
|
|
allowedIncludes = ['count.posts', 'permissions', 'roles', 'roles.permissions'];
|
|
|
|
|
|
|
|
let users;
|
2014-07-31 04:15:34 +04:00
|
|
|
|
2014-06-03 17:05:25 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ### Users 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
|
|
|
*/
|
2013-12-06 12:51:35 +04:00
|
|
|
users = {
|
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
|
|
|
/**
|
|
|
|
* ## Browse
|
|
|
|
* Fetch all users
|
2014-06-03 17:05:25 +04:00
|
|
|
* @param {{context}} options (optional)
|
2015-06-22 23:11:35 +03:00
|
|
|
* @returns {Promise<Users>} Users Collection
|
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
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
browse(options) {
|
|
|
|
let extraOptions = ['status', 'absolute_urls'],
|
2017-12-14 00:14:19 +03:00
|
|
|
permittedOptions = localUtils.browseDefaultOptions.concat(extraOptions),
|
2015-07-01 21:17:56 +03:00
|
|
|
tasks;
|
2015-06-22 23:11:35 +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.User.findPage(options)
|
|
|
|
.then(({data, meta}) => {
|
|
|
|
return {
|
2018-10-15 15:47:56 +03:00
|
|
|
users: data.map(model => urlsForUser(model.id, model.toJSON(options), options)),
|
2018-09-26 15:11:22 +03:00
|
|
|
meta: meta
|
|
|
|
};
|
|
|
|
});
|
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),
|
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'),
|
2015-07-01 21:17:56 +03:00
|
|
|
doQuery
|
|
|
|
];
|
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
|
|
|
},
|
|
|
|
|
2014-06-03 17:05:25 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Read
|
2014-06-03 17:05:25 +04:00
|
|
|
* @param {{id, context}} options
|
2015-06-22 23:11:35 +03:00
|
|
|
* @returns {Promise<Users>} User
|
2014-06-03 17:05:25 +04:00
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
read(options) {
|
|
|
|
let attrs = ['id', 'slug', 'status', 'email', 'role'],
|
2018-08-31 13:02:39 +03:00
|
|
|
permittedOptions = ['absolute_urls'],
|
2017-09-27 06:07:39 +03:00
|
|
|
tasks;
|
2015-06-22 23:11:35 +03:00
|
|
|
|
2017-02-23 21:04:24 +03:00
|
|
|
// Special handling for /users/me request
|
2017-09-27 06:07:39 +03:00
|
|
|
if (options.id === 'me' && options.context && options.context.user) {
|
2015-06-27 21:09:25 +03:00
|
|
|
options.id = options.context.user;
|
2014-07-08 20:00:59 +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 doQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.User.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.users.userNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
2018-10-15 15:47:56 +03:00
|
|
|
users: [urlsForUser(model.id, model.toJSON(options), options)]
|
2017-09-27 11:31:41 +03:00
|
|
|
};
|
|
|
|
});
|
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 = [
|
2018-08-31 13:02:39 +03:00
|
|
|
localUtils.validate(docName, {attrs: attrs, opts: permittedOptions}),
|
2017-12-14 00:14:19 +03:00
|
|
|
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.handlePublicPermissions(docName, 'read'),
|
2015-07-01 21:17:56 +03:00
|
|
|
doQuery
|
|
|
|
];
|
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
|
|
|
},
|
|
|
|
|
2014-06-03 17:05:25 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Edit
|
2014-06-03 17:05:25 +04:00
|
|
|
* @param {User} object the user details to edit
|
|
|
|
* @param {{id, context}} options
|
2015-06-22 23:11:35 +03:00
|
|
|
* @returns {Promise<User>}
|
2014-06-03 17:05:25 +04:00
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
edit(object, options) {
|
|
|
|
let extraOptions = ['editRoles'],
|
2017-12-14 00:14:19 +03:00
|
|
|
permittedOptions = extraOptions.concat(localUtils.idDefaultOptions),
|
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-07-01 21:17:56 +03:00
|
|
|
if (object.users && object.users[0] && object.users[0].roles && object.users[0].roles[0]) {
|
|
|
|
options.editRoles = true;
|
2014-07-24 13:46:05 +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-09-23 21:44:38 +03:00
|
|
|
// The password should never be set via this endpoint, if it is passed, ignore it
|
|
|
|
if (object.users && object.users[0] && object.users[0].password) {
|
|
|
|
delete object.users[0].password;
|
|
|
|
}
|
|
|
|
|
2018-10-06 03:25:46 +03:00
|
|
|
function prepare(options) {
|
2015-06-22 23:11:35 +03:00
|
|
|
if (options.id === 'me' && options.context && options.context.user) {
|
|
|
|
options.id = options.context.user;
|
|
|
|
}
|
2014-07-08 20:00:59 +04:00
|
|
|
|
2018-10-06 03:25:46 +03:00
|
|
|
return options;
|
2015-06-22 23:11:35 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### 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.User.edit(options.data.users[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.users.userNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
2018-10-15 15:47:56 +03:00
|
|
|
users: [urlsForUser(model.id, model.toJSON(options), options)]
|
2017-09-27 11:31:41 +03: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),
|
2018-10-06 03:25:46 +03:00
|
|
|
prepare,
|
|
|
|
localUtils.handlePermissions(docName, 'edit', ['status', 'roles']),
|
2015-07-01 21:17:56 +03:00
|
|
|
doQuery
|
|
|
|
];
|
2015-06-22 23:11:35 +03:00
|
|
|
|
2017-09-27 11:31:41 +03:00
|
|
|
return pipeline(tasks, object, options);
|
2014-06-20 13:15:01 +04:00
|
|
|
},
|
2014-04-03 17:03:09 +04:00
|
|
|
|
2014-07-24 13:46:05 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Destroy
|
2014-07-24 13:46:05 +04:00
|
|
|
* @param {{id, context}} options
|
2016-03-20 20:26:42 +03:00
|
|
|
* @returns {Promise}
|
2014-07-24 13:46:05 +04:00
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
destroy(options) {
|
|
|
|
let tasks;
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Handle Permissions
|
|
|
|
* We need to be an authorised user to perform this action
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function handlePermissions(options) {
|
2018-09-18 16:59:56 +03:00
|
|
|
return canThis(options.context).destroy.user(options.id).then(() => {
|
2015-06-22 23:11:35 +03:00
|
|
|
options.status = 'all';
|
|
|
|
return 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.NoPermissionError({
|
2016-10-06 15:27:35 +03:00
|
|
|
err: err,
|
2017-12-12 00:47:46 +03:00
|
|
|
context: common.i18n.t('errors.api.users.noPermissionToDestroyUser')
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2015-06-22 23:11:35 +03:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2016-03-20 20:26:42 +03:00
|
|
|
* ### Delete User
|
2015-06-22 23:11:35 +03:00
|
|
|
* Make the call to the Model layer
|
|
|
|
* @param {Object} options
|
|
|
|
*/
|
2016-03-20 20:26:42 +03:00
|
|
|
function deleteUser(options) {
|
2018-09-18 16:59:56 +03:00
|
|
|
return models.Base.transaction((t) => {
|
2016-03-20 20:26:42 +03:00
|
|
|
options.transacting = t;
|
|
|
|
|
|
|
|
return Promise.all([
|
2017-09-12 18:31:14 +03:00
|
|
|
models.Accesstoken.destroyByUser(options),
|
|
|
|
models.Refreshtoken.destroyByUser(options),
|
|
|
|
models.Post.destroyByAuthor(options)
|
2018-09-18 16:59:56 +03:00
|
|
|
]).then(() => {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.User.destroy(options);
|
2016-03-20 20:26:42 +03:00
|
|
|
}).return(null);
|
2018-09-18 16:59:56 +03:00
|
|
|
}).catch((err) => {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
2016-10-06 15:27:35 +03:00
|
|
|
err: err
|
|
|
|
}));
|
2014-07-24 13:46:05 +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
|
|
|
handlePermissions,
|
2016-03-20 20:26:42 +03:00
|
|
|
deleteUser
|
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
|
|
|
|
return pipeline(tasks, options);
|
2014-07-24 13:46:05 +04:00
|
|
|
},
|
|
|
|
|
2014-06-20 13:15:01 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Change Password
|
2014-07-09 02:28:31 +04:00
|
|
|
* @param {password} object
|
2014-06-20 13:15:01 +04:00
|
|
|
* @param {{context}} options
|
2015-06-22 23:11:35 +03:00
|
|
|
* @returns {Promise<password>} success message
|
2014-06-20 13:15:01 +04:00
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
changePassword(object, options) {
|
|
|
|
let tasks;
|
2015-06-22 23:11:35 +03:00
|
|
|
|
2016-11-07 14:18:50 +03:00
|
|
|
function validateRequest() {
|
2017-12-14 00:14:19 +03:00
|
|
|
return localUtils.validate('password')(object, options)
|
2018-09-18 16:59:56 +03:00
|
|
|
.then((options) => {
|
|
|
|
let data = options.data.password[0];
|
2016-11-07 14:18:50 +03:00
|
|
|
|
|
|
|
if (data.newPassword !== data.ne2Password) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.user.newPasswordsDoNotMatch')
|
2016-11-07 14:18:50 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.resolve(options);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2015-06-22 23:11:35 +03:00
|
|
|
/**
|
|
|
|
* ### Handle Permissions
|
|
|
|
* We need to be an authorised user to perform this action
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function handlePermissions(options) {
|
2018-09-18 16:59:56 +03:00
|
|
|
return canThis(options.context).edit.user(options.data.password[0].user_id).then(() => {
|
2015-06-22 23:11:35 +03:00
|
|
|
return 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.NoPermissionError({
|
2016-10-06 15:27:35 +03:00
|
|
|
err: err,
|
2017-12-12 00:47:46 +03:00
|
|
|
context: common.i18n.t('errors.api.users.noPermissionToChangeUsersPwd')
|
2016-10-06 15:27:35 +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 doQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.User.changePassword(
|
2015-07-07 16:32:50 +03:00
|
|
|
options.data.password[0],
|
2015-06-22 23:11:35 +03:00
|
|
|
_.omit(options, ['data'])
|
2018-09-18 16:59:56 +03:00
|
|
|
).then(() => {
|
2017-09-27 11:31:41 +03:00
|
|
|
return Promise.resolve({
|
2017-12-12 00:47:46 +03:00
|
|
|
password: [{message: common.i18n.t('notices.api.users.pwdChangedSuccessfully')}]
|
2017-09-27 11:31:41 +03: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 = [
|
2016-11-07 14:18:50 +03:00
|
|
|
validateRequest,
|
2017-12-14 00:14:19 +03:00
|
|
|
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
|
|
|
handlePermissions,
|
2015-07-01 21:17:56 +03:00
|
|
|
doQuery
|
|
|
|
];
|
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);
|
2014-07-30 19:40:30 +04:00
|
|
|
},
|
2013-12-06 12:51:35 +04:00
|
|
|
|
2014-07-30 19:40:30 +04:00
|
|
|
/**
|
2015-06-22 23:11:35 +03:00
|
|
|
* ## Transfer Ownership
|
|
|
|
* @param {owner} object
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Promise<User>}
|
2014-07-30 19:40:30 +04:00
|
|
|
*/
|
2018-09-18 16:59:56 +03:00
|
|
|
transferOwnership(object, options) {
|
|
|
|
let tasks;
|
2015-06-22 23:11:35 +03:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Handle Permissions
|
|
|
|
* We need to be an authorised user to perform this action
|
|
|
|
* @param {Object} options
|
|
|
|
* @returns {Object} options
|
|
|
|
*/
|
|
|
|
function handlePermissions(options) {
|
2018-09-18 16:59:56 +03:00
|
|
|
return models.Role.findOne({name: 'Owner'}).then((ownerRole) => {
|
2015-06-22 23:11:35 +03:00
|
|
|
return canThis(options.context).assign.role(ownerRole);
|
2018-09-18 16:59:56 +03:00
|
|
|
}).then(() => {
|
2015-06-22 23:11:35 +03:00
|
|
|
return options;
|
2014-07-30 19:40:30 +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 doQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.User.transferOwnership(options.data.owner[0], _.omit(options, ['data']))
|
2018-10-12 19:12:16 +03:00
|
|
|
.then((models) => {
|
2017-09-27 11:31:41 +03:00
|
|
|
return {
|
2018-10-12 19:12:16 +03:00
|
|
|
users: models.toJSON(_.omit(options, ['data']))
|
2017-09-27 11:31:41 +03: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('owner'),
|
|
|
|
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
|
|
|
handlePermissions,
|
2015-07-01 21:17:56 +03:00
|
|
|
doQuery
|
|
|
|
];
|
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);
|
2014-07-30 19:40:30 +04:00
|
|
|
}
|
2013-12-06 12:51:35 +04:00
|
|
|
};
|
|
|
|
|
|
|
|
module.exports = users;
|