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

230 lines
8.1 KiB
JavaScript
Raw Normal View History

const Promise = require('bluebird'),
{omit, merge} = require('lodash'),
pipeline = require('../../lib/promise/pipeline'),
mail = require('../../services/mail'),
urlUtils = require('../../lib/url-utils'),
localUtils = require('./utils'),
models = require('../../models'),
common = require('../../lib/common'),
security = require('../../lib/security'),
mailAPI = require('./mail'),
settingsAPI = require('./settings'),
docName = 'invites',
allowedIncludes = ['created_by', 'updated_by'],
unsafeAttrs = ['role_id'];
const invites = {
browse(options) {
let tasks;
function modelQuery(options) {
return models.Invite.findPage(options)
.then(({data, meta}) => {
return {
invites: data.map(model => model.toJSON(options)),
meta: meta
};
});
}
tasks = [
localUtils.validate(docName, {opts: localUtils.browseDefaultOptions}),
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'),
modelQuery
];
return pipeline(tasks, options);
},
read(options) {
const attrs = ['id', 'email'];
let tasks;
function modelQuery(options) {
return models.Invite.findOne(options.data, omit(options, ['data']))
.then((model) => {
if (!model) {
return Promise.reject(new common.errors.NotFoundError({
message: common.i18n.t('errors.api.invites.inviteNotFound')
}));
}
return {
invites: [model.toJSON(options)]
};
});
}
tasks = [
localUtils.validate(docName, {attrs: attrs}),
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'),
modelQuery
];
return pipeline(tasks, options);
},
destroy(options) {
let tasks;
function modelQuery(options) {
return models.Invite.findOne({id: options.id}, omit(options, ['data']))
.then((invite) => {
if (!invite) {
throw new common.errors.NotFoundError({message: common.i18n.t('errors.api.invites.inviteNotFound')});
}
return invite.destroy(options).return(null);
});
}
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
localUtils.handlePermissions(docName, 'destroy'),
modelQuery
];
return pipeline(tasks, options);
},
add(object, options) {
let loggedInUser = options.context.user,
tasks,
emailData,
invite;
function addInvite(options) {
const data = options.data;
return models.Invite.add(data.invites[0], omit(options, 'data'))
.then((_invite) => {
invite = _invite;
return settingsAPI.read({key: 'title'});
})
.then((response) => {
const adminUrl = urlUtils.urlFor('admin', true);
emailData = {
blogName: response.settings[0].value,
invitedByName: loggedInUser.get('name'),
invitedByEmail: loggedInUser.get('email'),
// @TODO: resetLink sounds weird
resetLink: urlUtils.urlJoin(adminUrl, 'signup', security.url.encodeBase64(invite.get('token')), '/')
};
return mail.utils.generateContent({data: emailData, template: 'invite-user'});
}).then((emailContent) => {
const payload = {
mail: [{
message: {
to: invite.get('email'),
subject: common.i18n.t('common.api.users.mail.invitedByName', {
invitedByName: emailData.invitedByName,
blogName: emailData.blogName
}),
html: emailContent.html,
text: emailContent.text
},
options: {}
}]
};
return mailAPI.send(payload, {context: {internal: true}});
}).then(() => {
options.id = invite.id;
return models.Invite.edit({status: 'sent'}, options);
}).then(() => {
invite.set('status', 'sent');
const inviteAsJSON = invite.toJSON();
return {
invites: [inviteAsJSON]
};
}).catch((error) => {
if (error && error.errorType === 'EmailError') {
const errorMessage = common.i18n.t('errors.api.invites.errorSendingEmail.error', {
message: error.message
});
const helpText = common.i18n.t('errors.api.invites.errorSendingEmail.help');
error.message = `${errorMessage} ${helpText}`;
common.logging.warn(error.message);
}
return Promise.reject(error);
});
}
function destroyOldInvite(options) {
const data = options.data;
return models.Invite.findOne({email: data.invites[0].email}, omit(options, 'data'))
.then((invite) => {
if (!invite) {
return Promise.resolve(options);
}
return invite.destroy(options);
})
.then(() => {
return options;
});
}
function validation(options) {
if (!options.data.invites[0].email) {
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.invites.emailIsRequired')}));
}
if (!options.data.invites[0].role_id) {
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.invites.roleIsRequired')}));
}
return options;
}
function checkIfUserExists(options) {
return models.User.findOne({email: options.data.invites[0].email}, options)
.then((user) => {
if (user) {
return Promise.reject(new common.errors.ValidationError({
message: common.i18n.t('errors.api.users.userAlreadyRegistered')
}));
}
return options;
});
}
function fetchLoggedInUser(options) {
return models.User.findOne({id: loggedInUser}, merge({}, omit(options, 'data'), {withRelated: ['roles']}))
.then((user) => {
if (!user) {
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.api.users.userNotFound')}));
}
loggedInUser = user;
return options;
});
}
tasks = [
localUtils.validate(docName, {opts: ['email']}),
localUtils.convertOptions(allowedIncludes),
validation,
localUtils.handlePermissions(docName, 'add', unsafeAttrs),
fetchLoggedInUser,
checkIfUserExists,
destroyOldInvite,
addInvite
];
return pipeline(tasks, object, options);
}
};
module.exports = invites;