2014-02-12 07:40:39 +04:00
|
|
|
var _ = require('lodash'),
|
2016-05-25 10:34:46 +03:00
|
|
|
Promise = require('bluebird'),
|
2017-12-14 05:01:23 +03:00
|
|
|
models = require('../../models'),
|
|
|
|
common = require('../../lib/common');
|
2014-02-12 07:40:39 +04:00
|
|
|
|
2017-10-05 22:01:34 +03:00
|
|
|
module.exports = {
|
2014-02-12 07:40:39 +04:00
|
|
|
user: function (id) {
|
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: id, status: 'all'}, {withRelated: ['permissions', 'roles', 'roles.permissions']})
|
2014-02-12 07:40:39 +04:00
|
|
|
.then(function (foundUser) {
|
2016-05-25 10:34:46 +03:00
|
|
|
// CASE: {context: {user: id}} where the id is not in our database
|
|
|
|
if (!foundUser) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.models.user.userNotFound')
|
|
|
|
}));
|
2016-05-25 10:34:46 +03:00
|
|
|
}
|
|
|
|
|
2014-02-12 07:40:39 +04:00
|
|
|
var seenPerms = {},
|
|
|
|
rolePerms = _.map(foundUser.related('roles').models, function (role) {
|
|
|
|
return role.related('permissions').models;
|
|
|
|
}),
|
2014-07-09 15:34:38 +04:00
|
|
|
allPerms = [],
|
|
|
|
user = foundUser.toJSON();
|
|
|
|
|
2014-02-12 07:40:39 +04:00
|
|
|
rolePerms.push(foundUser.related('permissions').models);
|
|
|
|
|
|
|
|
_.each(rolePerms, function (rolePermGroup) {
|
|
|
|
_.each(rolePermGroup, function (perm) {
|
|
|
|
var key = perm.get('action_type') + '-' + perm.get('object_type') + '-' + perm.get('object_id');
|
|
|
|
|
|
|
|
// Only add perms once
|
|
|
|
if (seenPerms[key]) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
allPerms.push(perm);
|
|
|
|
seenPerms[key] = true;
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2017-09-25 12:17:06 +03:00
|
|
|
// @TODO fix this!
|
|
|
|
// Permissions is an array of models
|
|
|
|
// Roles is a JSON array
|
2014-07-23 22:17:29 +04:00
|
|
|
return {permissions: allPerms, roles: user.roles};
|
2016-10-04 18:33:43 +03:00
|
|
|
});
|
2014-02-12 07:40:39 +04:00
|
|
|
},
|
|
|
|
|
|
|
|
app: function (appName) {
|
2017-09-25 12:17:06 +03:00
|
|
|
return models.App.findOne({name: appName}, {withRelated: ['permissions']})
|
2014-02-12 07:40:39 +04:00
|
|
|
.then(function (foundApp) {
|
|
|
|
if (!foundApp) {
|
|
|
|
return [];
|
|
|
|
}
|
|
|
|
|
2014-07-23 22:17:29 +04:00
|
|
|
return {permissions: foundApp.related('permissions').models};
|
2016-10-04 18:33:43 +03:00
|
|
|
});
|
2019-01-18 14:17:12 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
apiKey(id) {
|
|
|
|
return models.ApiKey.findOne({id}, {withRelated: ['role', 'role.permissions']})
|
|
|
|
.then((foundApiKey) => {
|
|
|
|
if (!foundApiKey) {
|
|
|
|
throw new common.errors.NotFoundError({
|
|
|
|
message: common.i18n.t('errors.models.api_key.apiKeyNotFound')
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
// api keys have a belongs_to relationship to a role and no individual permissions
|
|
|
|
// so there's no need for permission deduplication
|
|
|
|
const permissions = foundApiKey.related('role').related('permissions').models;
|
|
|
|
const roles = [foundApiKey.toJSON().role];
|
|
|
|
|
|
|
|
return {permissions, roles};
|
|
|
|
});
|
2014-02-12 07:40:39 +04:00
|
|
|
}
|
|
|
|
};
|