Ghost/core/server/api/v0.1/users.js

353 lines
11 KiB
JavaScript
Raw Normal View History

// # Users API
// RESTful API for the User resource
const Promise = require('bluebird'),
_ = require('lodash'),
pipeline = require('../../lib/promise/pipeline'),
localUtils = require('./utils'),
canThis = require('../../services/permissions').canThis,
models = require('../../models'),
common = require('../../lib/common'),
{urlsForUser} = require('./decorators/urls'),
docName = 'users',
allowedIncludes = ['count.posts', 'permissions', 'roles', 'roles.permissions'];
let users;
/**
* ### Users API Methods
*
* **See:** [API Methods](constants.js.html#api%20methods)
*/
users = {
/**
* ## Browse
* Fetch all users
* @param {{context}} options (optional)
* @returns {Promise<Users>} Users Collection
*/
browse(options) {
let extraOptions = ['status', 'absolute_urls'],
permittedOptions = localUtils.browseDefaultOptions.concat(extraOptions),
tasks;
/**
* ### Model Query
* Make the call to the Model layer
* @param {Object} options
* @returns {Object} options
*/
function doQuery(options) {
return models.User.findPage(options)
.then(({data, meta}) => {
return {
users: data.map(model => urlsForUser(model.id, model.toJSON(options), options)),
meta: meta
};
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
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'),
doQuery
];
// Pipeline calls each task passing the result of one to be the arguments for the next
return pipeline(tasks, options);
},
/**
* ## Read
* @param {{id, context}} options
* @returns {Promise<Users>} User
*/
read(options) {
let attrs = ['id', 'slug', 'status', 'email', 'role'],
permittedOptions = ['absolute_urls'],
tasks;
// Special handling for /users/me request
if (options.id === 'me' && options.context && options.context.user) {
options.id = options.context.user;
}
/**
* ### Model Query
* Make the call to the Model layer
* @param {Object} options
* @returns {Object} options
*/
function doQuery(options) {
return models.User.findOne(options.data, _.omit(options, ['data']))
.then((model) => {
if (!model) {
return Promise.reject(new common.errors.NotFoundError({
message: common.i18n.t('errors.api.users.userNotFound')
}));
}
return {
users: [urlsForUser(model.id, model.toJSON(options), options)]
};
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
localUtils.validate(docName, {attrs: attrs, 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, 'read'),
doQuery
];
// Pipeline calls each task passing the result of one to be the arguments for the next
return pipeline(tasks, options);
},
/**
* ## Edit
* @param {User} object the user details to edit
* @param {{id, context}} options
* @returns {Promise<User>}
*/
edit(object, options) {
let extraOptions = ['editRoles'],
permittedOptions = extraOptions.concat(localUtils.idDefaultOptions),
tasks;
if (object.users && object.users[0] && object.users[0].roles && object.users[0].roles[0]) {
options.editRoles = true;
}
// 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;
}
function prepare(options) {
if (options.id === 'me' && options.context && options.context.user) {
options.id = options.context.user;
}
return options;
}
/**
* ### Model Query
* Make the call to the Model layer
* @param {Object} options
* @returns {Object} options
*/
function doQuery(options) {
return models.User.edit(options.data.users[0], _.omit(options, ['data']))
.then((model) => {
if (!model) {
return Promise.reject(new common.errors.NotFoundError({
message: common.i18n.t('errors.api.users.userNotFound')
}));
}
return {
users: [urlsForUser(model.id, model.toJSON(options), options)]
};
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
localUtils.validate(docName, {opts: permittedOptions}),
localUtils.convertOptions(allowedIncludes),
prepare,
localUtils.handlePermissions(docName, 'edit', ['status', 'roles']),
doQuery
];
return pipeline(tasks, object, options);
},
/**
* ## Destroy
* @param {{id, context}} options
* @returns {Promise}
*/
destroy(options) {
let tasks;
/**
* ### Handle Permissions
* We need to be an authorised user to perform this action
* @param {Object} options
* @returns {Object} options
*/
function handlePermissions(options) {
return canThis(options.context).destroy.user(options.id).then(() => {
options.status = 'all';
return options;
}).catch((err) => {
return Promise.reject(new common.errors.NoPermissionError({
err: err,
context: common.i18n.t('errors.api.users.noPermissionToDestroyUser')
}));
});
}
/**
* ### Delete User
* Make the call to the Model layer
* @param {Object} options
*/
function deleteUser(options) {
return models.Base.transaction((t) => {
options.transacting = t;
return Promise.all([
models.Accesstoken.destroyByUser(options),
models.Refreshtoken.destroyByUser(options),
models.Post.destroyByAuthor(options)
]).then(() => {
return models.User.destroy(options);
}).return(null);
}).catch((err) => {
return Promise.reject(new common.errors.NoPermissionError({
err: err
}));
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
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,
deleteUser
];
// Pipeline calls each task passing the result of one to be the arguments for the next
return pipeline(tasks, options);
},
/**
* ## Change Password
* @param {password} object
* @param {{context}} options
* @returns {Promise<password>} success message
*/
changePassword(object, options) {
let tasks;
🎨 remove token logic from user model (#7622) * 🔥 remove User model functions - validateToken - generateToken - resetPassword - all this logic will re-appear in a different way Token logic: - was already extracted as separate PR, see https://github.com/TryGhost/Ghost/pull/7554 - we will use this logic in the controller, you will see in the next commits Reset Password: Was just a wrapper for calling the token logic and change the password. We can reconsider keeping the function to call: changePassword and activate the status of the user - but i think it's fine to trigger these two actions from the controlling unit. * 🔥 remove password reset tests from User model - we already have unit tests for change password and the token logic - i will re-check at the end if any test case is missing - but for now i will just burn the tests * ✨ add token logic to controlling unit generateResetToken endpoint - the only change here is instead of calling the User model to generate a token, we generate the token via utils - we fetch the user by email, and generate a hash and return resetPassword endpoint - here we have changed a little bit more - first of all: we have added the validation check if the new passwords match - a new helper method to extract the token informations - the brute force security check, which can be handled later from the new bruteforce middleware (see TODO) - the actual reset function is doing the steps: load me the user, compare the token, change the password and activate the user - we can think of wrapping these steps into a User model function - i was not sure about it, because it is actually part of the controlling unit [ci skip] * 🎨 tidy up - jscs - jshint - naming functions - fixes * ✨ add a test for resetting the password - there was none - added a test to reset the password * 🎨 add more token tests - ensure quality - ensure logic we had * 🔥 remove compare new password check from User Model - this part of controlling unit * ✨ compare new passwords for user endpoint - we deleted the logic in User Model - we are adding the logic to controlling unit * 🐛 spam prevention forgotten can crash - no validation happend before this middleware - it just assumes that the root key is present - when we work on our API, we need to ensure that 1. pre validation happens 2. we call middlewares 3. ... * 🎨 token translation key
2016-11-07 14:18:50 +03:00
function validateRequest() {
return localUtils.validate('password')(object, options)
.then((options) => {
let data = options.data.password[0];
🎨 remove token logic from user model (#7622) * 🔥 remove User model functions - validateToken - generateToken - resetPassword - all this logic will re-appear in a different way Token logic: - was already extracted as separate PR, see https://github.com/TryGhost/Ghost/pull/7554 - we will use this logic in the controller, you will see in the next commits Reset Password: Was just a wrapper for calling the token logic and change the password. We can reconsider keeping the function to call: changePassword and activate the status of the user - but i think it's fine to trigger these two actions from the controlling unit. * 🔥 remove password reset tests from User model - we already have unit tests for change password and the token logic - i will re-check at the end if any test case is missing - but for now i will just burn the tests * ✨ add token logic to controlling unit generateResetToken endpoint - the only change here is instead of calling the User model to generate a token, we generate the token via utils - we fetch the user by email, and generate a hash and return resetPassword endpoint - here we have changed a little bit more - first of all: we have added the validation check if the new passwords match - a new helper method to extract the token informations - the brute force security check, which can be handled later from the new bruteforce middleware (see TODO) - the actual reset function is doing the steps: load me the user, compare the token, change the password and activate the user - we can think of wrapping these steps into a User model function - i was not sure about it, because it is actually part of the controlling unit [ci skip] * 🎨 tidy up - jscs - jshint - naming functions - fixes * ✨ add a test for resetting the password - there was none - added a test to reset the password * 🎨 add more token tests - ensure quality - ensure logic we had * 🔥 remove compare new password check from User Model - this part of controlling unit * ✨ compare new passwords for user endpoint - we deleted the logic in User Model - we are adding the logic to controlling unit * 🐛 spam prevention forgotten can crash - no validation happend before this middleware - it just assumes that the root key is present - when we work on our API, we need to ensure that 1. pre validation happens 2. we call middlewares 3. ... * 🎨 token translation key
2016-11-07 14:18:50 +03:00
if (data.newPassword !== data.ne2Password) {
return Promise.reject(new common.errors.ValidationError({
message: common.i18n.t('errors.models.user.newPasswordsDoNotMatch')
🎨 remove token logic from user model (#7622) * 🔥 remove User model functions - validateToken - generateToken - resetPassword - all this logic will re-appear in a different way Token logic: - was already extracted as separate PR, see https://github.com/TryGhost/Ghost/pull/7554 - we will use this logic in the controller, you will see in the next commits Reset Password: Was just a wrapper for calling the token logic and change the password. We can reconsider keeping the function to call: changePassword and activate the status of the user - but i think it's fine to trigger these two actions from the controlling unit. * 🔥 remove password reset tests from User model - we already have unit tests for change password and the token logic - i will re-check at the end if any test case is missing - but for now i will just burn the tests * ✨ add token logic to controlling unit generateResetToken endpoint - the only change here is instead of calling the User model to generate a token, we generate the token via utils - we fetch the user by email, and generate a hash and return resetPassword endpoint - here we have changed a little bit more - first of all: we have added the validation check if the new passwords match - a new helper method to extract the token informations - the brute force security check, which can be handled later from the new bruteforce middleware (see TODO) - the actual reset function is doing the steps: load me the user, compare the token, change the password and activate the user - we can think of wrapping these steps into a User model function - i was not sure about it, because it is actually part of the controlling unit [ci skip] * 🎨 tidy up - jscs - jshint - naming functions - fixes * ✨ add a test for resetting the password - there was none - added a test to reset the password * 🎨 add more token tests - ensure quality - ensure logic we had * 🔥 remove compare new password check from User Model - this part of controlling unit * ✨ compare new passwords for user endpoint - we deleted the logic in User Model - we are adding the logic to controlling unit * 🐛 spam prevention forgotten can crash - no validation happend before this middleware - it just assumes that the root key is present - when we work on our API, we need to ensure that 1. pre validation happens 2. we call middlewares 3. ... * 🎨 token translation key
2016-11-07 14:18:50 +03:00
}));
}
return Promise.resolve(options);
});
}
/**
* ### Handle Permissions
* We need to be an authorised user to perform this action
* @param {Object} options
* @returns {Object} options
*/
function handlePermissions(options) {
return canThis(options.context).edit.user(options.data.password[0].user_id).then(() => {
return options;
}).catch((err) => {
return Promise.reject(new common.errors.NoPermissionError({
err: err,
context: common.i18n.t('errors.api.users.noPermissionToChangeUsersPwd')
}));
});
}
/**
* ### Model Query
* Make the call to the Model layer
* @param {Object} options
* @returns {Object} options
*/
function doQuery(options) {
return models.User.changePassword(
options.data.password[0],
_.omit(options, ['data'])
).then(() => {
return Promise.resolve({
password: [{message: common.i18n.t('notices.api.users.pwdChangedSuccessfully')}]
});
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
🎨 remove token logic from user model (#7622) * 🔥 remove User model functions - validateToken - generateToken - resetPassword - all this logic will re-appear in a different way Token logic: - was already extracted as separate PR, see https://github.com/TryGhost/Ghost/pull/7554 - we will use this logic in the controller, you will see in the next commits Reset Password: Was just a wrapper for calling the token logic and change the password. We can reconsider keeping the function to call: changePassword and activate the status of the user - but i think it's fine to trigger these two actions from the controlling unit. * 🔥 remove password reset tests from User model - we already have unit tests for change password and the token logic - i will re-check at the end if any test case is missing - but for now i will just burn the tests * ✨ add token logic to controlling unit generateResetToken endpoint - the only change here is instead of calling the User model to generate a token, we generate the token via utils - we fetch the user by email, and generate a hash and return resetPassword endpoint - here we have changed a little bit more - first of all: we have added the validation check if the new passwords match - a new helper method to extract the token informations - the brute force security check, which can be handled later from the new bruteforce middleware (see TODO) - the actual reset function is doing the steps: load me the user, compare the token, change the password and activate the user - we can think of wrapping these steps into a User model function - i was not sure about it, because it is actually part of the controlling unit [ci skip] * 🎨 tidy up - jscs - jshint - naming functions - fixes * ✨ add a test for resetting the password - there was none - added a test to reset the password * 🎨 add more token tests - ensure quality - ensure logic we had * 🔥 remove compare new password check from User Model - this part of controlling unit * ✨ compare new passwords for user endpoint - we deleted the logic in User Model - we are adding the logic to controlling unit * 🐛 spam prevention forgotten can crash - no validation happend before this middleware - it just assumes that the root key is present - when we work on our API, we need to ensure that 1. pre validation happens 2. we call middlewares 3. ... * 🎨 token translation key
2016-11-07 14:18:50 +03:00
validateRequest,
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,
doQuery
];
// Pipeline calls each task passing the result of one to be the arguments for the next
return pipeline(tasks, object, options);
},
/**
* ## Transfer Ownership
* @param {owner} object
* @param {Object} options
* @returns {Promise<User>}
*/
transferOwnership(object, options) {
let tasks;
/**
* ### Handle Permissions
* We need to be an authorised user to perform this action
* @param {Object} options
* @returns {Object} options
*/
function handlePermissions(options) {
return models.Role.findOne({name: 'Owner'}).then((ownerRole) => {
return canThis(options.context).assign.role(ownerRole);
}).then(() => {
return options;
});
}
/**
* ### Model Query
* Make the call to the Model layer
* @param {Object} options
* @returns {Object} options
*/
function doQuery(options) {
return models.User.transferOwnership(options.data.owner[0], _.omit(options, ['data']))
.then((models) => {
return {
users: models.toJSON(_.omit(options, ['data']))
};
});
}
// Push all of our tasks into a `tasks` array in the correct order
tasks = [
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,
doQuery
];
// Pipeline calls each task passing the result of one to be the arguments for the next
return pipeline(tasks, object, options);
}
};
module.exports = users;