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 05:01:23 +03:00
|
|
|
mail = require('../services/mail'),
|
2017-12-11 21:14:05 +03:00
|
|
|
urlService = require('../services/url'),
|
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-12-14 15:26:48 +03:00
|
|
|
security = require('../lib/security'),
|
2017-09-12 18:31:14 +03:00
|
|
|
mailAPI = require('./mail'),
|
|
|
|
settingsAPI = require('./settings'),
|
2016-09-21 17:48:14 +03:00
|
|
|
docName = 'invites',
|
2016-11-16 12:33:44 +03:00
|
|
|
allowedIncludes = ['created_by', 'updated_by'],
|
2016-09-21 17:48:14 +03:00
|
|
|
invites;
|
|
|
|
|
|
|
|
invites = {
|
|
|
|
browse: function browse(options) {
|
|
|
|
var tasks;
|
|
|
|
|
|
|
|
function modelQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Invite.findPage(options);
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
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'),
|
2016-09-21 17:48:14 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
read: function read(options) {
|
|
|
|
var attrs = ['id', 'email'],
|
|
|
|
tasks;
|
|
|
|
|
|
|
|
function modelQuery(options) {
|
2017-09-27 11:31:41 +03:00
|
|
|
return models.Invite.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.invites.inviteNotFound')
|
2017-09-27 11:31:41 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
invites: [model.toJSON(options)]
|
|
|
|
};
|
|
|
|
});
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
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'),
|
2016-09-21 17:48:14 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
|
|
|
|
2017-09-27 11:31:41 +03:00
|
|
|
return pipeline(tasks, options);
|
2016-09-21 17:48:14 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
destroy: function destroy(options) {
|
|
|
|
var tasks;
|
|
|
|
|
|
|
|
function modelQuery(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Invite.findOne({id: options.id}, _.omit(options, ['data']))
|
2016-09-21 17:48:14 +03:00
|
|
|
.then(function (invite) {
|
|
|
|
if (!invite) {
|
2017-12-12 00:47:46 +03:00
|
|
|
throw new common.errors.NotFoundError({message: common.i18n.t('errors.api.invites.inviteNotFound')});
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return invite.destroy(options).return(null);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
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'),
|
2016-09-21 17:48:14 +03:00
|
|
|
modelQuery
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, options);
|
|
|
|
},
|
|
|
|
|
|
|
|
add: function add(object, options) {
|
|
|
|
var tasks,
|
|
|
|
loggedInUser = options.context.user,
|
|
|
|
emailData,
|
|
|
|
invite;
|
|
|
|
|
|
|
|
function addInvite(options) {
|
|
|
|
var data = options.data;
|
|
|
|
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Invite.add(data.invites[0], _.omit(options, 'data'))
|
2016-09-21 17:48:14 +03:00
|
|
|
.then(function (_invite) {
|
|
|
|
invite = _invite;
|
|
|
|
|
2017-09-12 18:31:14 +03:00
|
|
|
return settingsAPI.read({key: 'title'});
|
2016-09-21 17:48:14 +03:00
|
|
|
})
|
|
|
|
.then(function (response) {
|
2017-12-11 21:14:05 +03:00
|
|
|
var adminUrl = urlService.utils.urlFor('admin', true);
|
2016-09-21 17:48:14 +03:00
|
|
|
|
|
|
|
emailData = {
|
|
|
|
blogName: response.settings[0].value,
|
|
|
|
invitedByName: loggedInUser.get('name'),
|
|
|
|
invitedByEmail: loggedInUser.get('email'),
|
|
|
|
// @TODO: resetLink sounds weird
|
2017-12-14 15:26:48 +03:00
|
|
|
resetLink: urlService.utils.urlJoin(adminUrl, 'signup', security.url.encodeBase64(invite.get('token')), '/')
|
2016-09-21 17:48:14 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
return mail.utils.generateContent({data: emailData, template: 'invite-user'});
|
|
|
|
}).then(function (emailContent) {
|
|
|
|
var payload = {
|
|
|
|
mail: [{
|
|
|
|
message: {
|
|
|
|
to: invite.get('email'),
|
2017-12-12 00:47:46 +03:00
|
|
|
subject: common.i18n.t('common.api.users.mail.invitedByName', {
|
2016-09-21 17:48:14 +03:00
|
|
|
invitedByName: emailData.invitedByName,
|
|
|
|
blogName: emailData.blogName
|
|
|
|
}),
|
|
|
|
html: emailContent.html,
|
|
|
|
text: emailContent.text
|
|
|
|
},
|
|
|
|
options: {}
|
|
|
|
}]
|
|
|
|
};
|
|
|
|
|
2017-09-12 18:31:14 +03:00
|
|
|
return mailAPI.send(payload, {context: {internal: true}});
|
2016-09-21 17:48:14 +03:00
|
|
|
}).then(function () {
|
|
|
|
options.id = invite.id;
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Invite.edit({status: 'sent'}, options);
|
2016-09-21 17:48:14 +03:00
|
|
|
}).then(function () {
|
|
|
|
invite.set('status', 'sent');
|
|
|
|
var inviteAsJSON = invite.toJSON();
|
2017-09-27 11:31:41 +03:00
|
|
|
|
|
|
|
return {
|
|
|
|
invites: [inviteAsJSON]
|
|
|
|
};
|
2016-09-21 17:48:14 +03:00
|
|
|
}).catch(function (error) {
|
|
|
|
if (error && error.errorType === 'EmailError') {
|
2017-12-12 00:47:46 +03:00
|
|
|
error.message = common.i18n.t('errors.api.invites.errorSendingEmail.error', {message: error.message}) + ' ' +
|
|
|
|
common.i18n.t('errors.api.invites.errorSendingEmail.help');
|
|
|
|
common.logging.warn(error.message);
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.reject(error);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function destroyOldInvite(options) {
|
|
|
|
var data = options.data;
|
|
|
|
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Invite.findOne({email: data.invites[0].email}, _.omit(options, 'data'))
|
2016-09-21 17:48:14 +03:00
|
|
|
.then(function (invite) {
|
|
|
|
if (!invite) {
|
|
|
|
return Promise.resolve(options);
|
|
|
|
}
|
|
|
|
|
|
|
|
return invite.destroy(options);
|
|
|
|
})
|
|
|
|
.then(function () {
|
|
|
|
return options;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
function validation(options) {
|
|
|
|
if (!options.data.invites[0].email) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.invites.emailIsRequired')}));
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
2016-11-16 12:33:44 +03:00
|
|
|
if (!options.data.invites[0].role_id) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({message: common.i18n.t('errors.api.invites.roleIsRequired')}));
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
|
|
|
|
2017-01-25 15:07:31 +03:00
|
|
|
// @TODO remove when we have a new permission unit
|
2016-09-21 17:48:14 +03:00
|
|
|
// Make sure user is allowed to add a user with this role
|
2017-01-25 15:07:31 +03:00
|
|
|
// We cannot use permissible because we don't have access to the role_id!!!
|
|
|
|
// Adding a permissible function to the invite model, doesn't give us much context of the invite we would like to add
|
|
|
|
// As we are looking forward to replace the permission system completely, we do not add a hack here
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.Role.findOne({id: options.data.invites[0].role_id}).then(function (roleToInvite) {
|
2017-01-25 15:07:31 +03:00
|
|
|
if (!roleToInvite) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.api.invites.roleNotFound')}));
|
2016-11-16 12:33:44 +03:00
|
|
|
}
|
|
|
|
|
2017-01-25 15:07:31 +03:00
|
|
|
if (roleToInvite.get('name') === 'Owner') {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NoPermissionError({message: common.i18n.t('errors.api.invites.notAllowedToInviteOwner')}));
|
2016-09-21 17:48:14 +03:00
|
|
|
}
|
2017-01-25 15:07:31 +03:00
|
|
|
|
|
|
|
var loggedInUserRole = loggedInUser.related('roles').models[0].get('name'),
|
|
|
|
allowed = [];
|
|
|
|
|
|
|
|
if (loggedInUserRole === 'Owner' || loggedInUserRole === 'Administrator') {
|
2018-02-07 12:46:22 +03:00
|
|
|
allowed = ['Administrator', 'Editor', 'Author', 'Contributor'];
|
2017-01-25 15:07:31 +03:00
|
|
|
} else if (loggedInUserRole === 'Editor') {
|
2018-02-07 12:46:22 +03:00
|
|
|
allowed = ['Author', 'Contributor'];
|
2017-01-25 15:07:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (allowed.indexOf(roleToInvite.get('name')) === -1) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.api.invites.notAllowedToInvite')
|
2017-01-25 15:07:31 +03:00
|
|
|
}));
|
|
|
|
}
|
2016-09-21 17:48:14 +03:00
|
|
|
}).then(function () {
|
|
|
|
return options;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2017-07-14 22:55:49 +03:00
|
|
|
function checkIfUserExists(options) {
|
2017-09-12 18:31:14 +03:00
|
|
|
return models.User.findOne({email: options.data.invites[0].email}, options)
|
2017-07-14 22:55:49 +03:00
|
|
|
.then(function (user) {
|
|
|
|
if (user) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.api.users.userAlreadyRegistered')
|
2017-07-14 22:55:49 +03:00
|
|
|
}));
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2017-01-25 15:07:31 +03:00
|
|
|
function fetchLoggedInUser(options) {
|
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
|
|
|
return models.User.findOne({id: loggedInUser}, _.merge({}, _.omit(options, 'data'), {withRelated: ['roles']}))
|
2017-01-25 15:07:31 +03:00
|
|
|
.then(function (user) {
|
|
|
|
if (!user) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({message: common.i18n.t('errors.api.users.userNotFound')}));
|
2017-01-25 15:07:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
loggedInUser = user;
|
|
|
|
return options;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2016-09-21 17:48:14 +03:00
|
|
|
tasks = [
|
2017-12-14 00:14:19 +03:00
|
|
|
localUtils.validate(docName, {opts: ['email']}),
|
|
|
|
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'),
|
2017-01-25 15:07:31 +03:00
|
|
|
fetchLoggedInUser,
|
2016-09-21 17:48:14 +03:00
|
|
|
validation,
|
2017-07-14 22:55:49 +03:00
|
|
|
checkIfUserExists,
|
2016-09-21 17:48:14 +03:00
|
|
|
destroyOldInvite,
|
|
|
|
addInvite
|
|
|
|
];
|
|
|
|
|
|
|
|
return pipeline(tasks, object, options);
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
module.exports = invites;
|