Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
// # Base Model
|
|
|
|
// This is the model from which all other Ghost models extend. The model is based on Bookshelf.Model, and provides
|
|
|
|
// several basic behaviours such as UUIDs, as well as a set of Data methods for accessing information from the database.
|
|
|
|
//
|
|
|
|
// The models are internal to Ghost, only the API and some internal functions such as migration and import/export
|
2020-03-19 18:23:10 +03:00
|
|
|
// accesses the models directly.
|
|
|
|
|
|
|
|
// All other parts of Ghost, including the frontend & admin UI are only allowed to access data via the API.
|
2020-04-29 18:44:27 +03:00
|
|
|
const _ = require('lodash');
|
|
|
|
|
|
|
|
const bookshelf = require('bookshelf');
|
|
|
|
const moment = require('moment');
|
|
|
|
const Promise = require('bluebird');
|
|
|
|
const ObjectId = require('bson-objectid');
|
|
|
|
const debug = require('ghost-ignition').debug('models:base');
|
2020-05-27 20:47:53 +03:00
|
|
|
const config = require('../../../shared/config');
|
2020-04-29 18:44:27 +03:00
|
|
|
const db = require('../../data/db');
|
2021-04-27 16:18:04 +03:00
|
|
|
const events = require('../../lib/common/events');
|
2020-05-28 21:30:23 +03:00
|
|
|
const logging = require('../../../shared/logging');
|
2020-05-22 21:22:20 +03:00
|
|
|
const errors = require('@tryghost/errors');
|
2020-08-11 16:01:16 +03:00
|
|
|
const security = require('@tryghost/security');
|
2020-04-29 18:44:27 +03:00
|
|
|
const schema = require('../../data/schema');
|
2020-05-28 13:57:02 +03:00
|
|
|
const urlUtils = require('../../../shared/url-utils');
|
2020-08-20 11:24:05 +03:00
|
|
|
const bulkOperations = require('./bulk-operations');
|
2021-06-15 13:57:47 +03:00
|
|
|
const plugins = require('@tryghost/bookshelf-plugins');
|
2021-06-14 19:18:25 +03:00
|
|
|
const tpl = require('@tryghost/tpl');
|
|
|
|
|
|
|
|
const messages = {
|
|
|
|
missingContext: 'missing context',
|
|
|
|
invalidDate: 'Date format for `{key}` is invalid.'
|
|
|
|
};
|
|
|
|
|
2020-04-29 18:44:27 +03:00
|
|
|
let ghostBookshelf;
|
|
|
|
let proto;
|
2013-06-25 15:43:15 +04:00
|
|
|
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
// ### ghostBookshelf
|
|
|
|
// Initializes a new Bookshelf instance called ghostBookshelf, for reference elsewhere in Ghost.
|
2016-02-12 14:56:27 +03:00
|
|
|
ghostBookshelf = bookshelf(db.knex);
|
2014-08-14 01:58:12 +04:00
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// Load the Bookshelf registry plugin, which helps us avoid circular dependencies
|
2014-07-13 15:17:18 +04:00
|
|
|
ghostBookshelf.plugin('registry');
|
2013-06-25 15:43:15 +04:00
|
|
|
|
2020-09-24 04:32:40 +03:00
|
|
|
ghostBookshelf.plugin(plugins.eagerLoad);
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
// Add committed/rollback events.
|
|
|
|
ghostBookshelf.plugin(plugins.transactionEvents);
|
|
|
|
|
2020-06-12 14:12:10 +03:00
|
|
|
// Load the Ghost custom-query plugin, which applying a custom query to findPage requests
|
|
|
|
ghostBookshelf.plugin(plugins.customQuery);
|
|
|
|
|
2015-11-11 20:52:44 +03:00
|
|
|
// Load the Ghost filter plugin, which handles applying a 'filter' to findPage requests
|
|
|
|
ghostBookshelf.plugin(plugins.filter);
|
|
|
|
|
2020-09-08 07:15:47 +03:00
|
|
|
// Load the Ghost filter plugin, which handles applying a 'order' to findPage requests
|
|
|
|
ghostBookshelf.plugin(plugins.order);
|
|
|
|
|
2020-05-28 12:14:02 +03:00
|
|
|
// Load the Ghost search plugin, which handles applying a search query to findPage requests
|
|
|
|
ghostBookshelf.plugin(plugins.search);
|
|
|
|
|
2015-11-03 14:38:29 +03:00
|
|
|
// Load the Ghost include count plugin, which allows for the inclusion of cross-table counts
|
2015-11-11 21:24:24 +03:00
|
|
|
ghostBookshelf.plugin(plugins.includeCount);
|
2015-11-03 14:38:29 +03:00
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// Load the Ghost pagination plugin, which gives us the `fetchPage` method on Models
|
2015-11-11 21:24:24 +03:00
|
|
|
ghostBookshelf.plugin(plugins.pagination);
|
2015-06-17 16:55:39 +03:00
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
// Update collision plugin
|
|
|
|
ghostBookshelf.plugin(plugins.collision);
|
|
|
|
|
2019-01-03 22:30:35 +03:00
|
|
|
// Load hasPosts plugin for authors models
|
|
|
|
ghostBookshelf.plugin(plugins.hasPosts);
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
// Manages nested updates (relationships)
|
|
|
|
ghostBookshelf.plugin('bookshelf-relations', {
|
2018-07-24 15:37:17 +03:00
|
|
|
allowedOptions: ['context', 'importing', 'migrating'],
|
2017-11-21 16:28:05 +03:00
|
|
|
unsetRelations: true,
|
2019-02-02 12:24:53 +03:00
|
|
|
extendChanged: '_changed',
|
2019-02-03 16:18:46 +03:00
|
|
|
attachPreviousRelations: true,
|
2017-11-21 16:28:05 +03:00
|
|
|
hooks: {
|
|
|
|
belongsToMany: {
|
|
|
|
after: function (existing, targets, options) {
|
2018-03-27 17:16:15 +03:00
|
|
|
// reorder tags/authors
|
2020-04-29 18:44:27 +03:00
|
|
|
const queryOptions = {
|
2018-03-27 17:16:15 +03:00
|
|
|
query: {
|
|
|
|
where: {}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2018-04-25 13:27:39 +03:00
|
|
|
// CASE: disable after hook for specific relations
|
|
|
|
if (['permissions_roles'].indexOf(existing.relatedData.joinTableName) !== -1) {
|
|
|
|
return Promise.resolve();
|
|
|
|
}
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
return Promise.each(targets.models, function (target, index) {
|
2018-03-27 17:16:15 +03:00
|
|
|
queryOptions.query.where[existing.relatedData.otherKey] = target.id;
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
return existing.updatePivot({
|
|
|
|
sort_order: index
|
2018-03-27 17:16:15 +03:00
|
|
|
}, _.extend({}, options, queryOptions));
|
2017-11-21 16:28:05 +03:00
|
|
|
});
|
|
|
|
},
|
|
|
|
beforeRelationCreation: function onCreatingRelation(model, data) {
|
2021-04-21 18:02:02 +03:00
|
|
|
data.id = ObjectId().toHexString();
|
2017-11-21 16:28:05 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2015-11-20 15:04:49 +03:00
|
|
|
// Cache an instance of the base model prototype
|
|
|
|
proto = ghostBookshelf.Model.prototype;
|
|
|
|
|
2019-02-07 00:05:03 +03:00
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
*
|
|
|
|
* We add actions step by step and define how they should look like.
|
|
|
|
* Each post update triggers a couple of events, which we don't want to add actions for.
|
|
|
|
*
|
|
|
|
* e.g. transform post to page triggers a handful of events including `post.deleted` and `page.added`
|
|
|
|
*
|
|
|
|
* We protect adding too many and uncontrolled events.
|
|
|
|
*
|
|
|
|
* We could embedd adding actions more nicely in the future e.g. plugin.
|
|
|
|
*/
|
|
|
|
const addAction = (model, event, options) => {
|
2019-02-08 00:06:13 +03:00
|
|
|
if (!model.wasChanged()) {
|
2019-02-07 22:49:35 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-02-07 00:05:03 +03:00
|
|
|
// CASE: model does not support actions at all
|
|
|
|
if (!model.getAction) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
const existingAction = model.getAction(event, options);
|
2019-02-07 00:05:03 +03:00
|
|
|
|
|
|
|
// CASE: model does not support action for target event
|
2020-10-20 02:02:56 +03:00
|
|
|
if (!existingAction) {
|
2019-02-07 00:05:03 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
const insert = (action) => {
|
|
|
|
ghostBookshelf.model('Action')
|
|
|
|
.add(action)
|
|
|
|
.catch((err) => {
|
|
|
|
if (_.isArray(err)) {
|
|
|
|
err = err[0];
|
|
|
|
}
|
|
|
|
|
2020-05-22 21:22:20 +03:00
|
|
|
logging.error(new errors.InternalServerError({
|
2019-02-07 00:05:03 +03:00
|
|
|
err
|
|
|
|
}));
|
|
|
|
});
|
|
|
|
};
|
|
|
|
|
|
|
|
if (options.transacting) {
|
|
|
|
options.transacting.once('committed', (committed) => {
|
|
|
|
if (!committed) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
insert(existingAction);
|
2019-02-07 00:05:03 +03:00
|
|
|
});
|
|
|
|
} else {
|
2020-10-20 02:02:56 +03:00
|
|
|
insert(existingAction);
|
2019-02-07 00:05:03 +03:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// ## ghostBookshelf.Model
|
2013-06-25 15:43:15 +04:00
|
|
|
// The Base Model which other Ghost objects will inherit from,
|
|
|
|
// including some convenience functions as static properties on the model.
|
2013-09-23 02:20:08 +04:00
|
|
|
ghostBookshelf.Model = ghostBookshelf.Model.extend({
|
2015-06-17 16:55:39 +03:00
|
|
|
// Bookshelf `hasTimestamps` - handles created_at and updated_at properties
|
2013-09-14 23:01:46 +04:00
|
|
|
hasTimestamps: true,
|
|
|
|
|
2018-03-19 18:27:06 +03:00
|
|
|
// https://github.com/bookshelf/bookshelf/commit/a55db61feb8ad5911adb4f8c3b3d2a97a45bd6db
|
|
|
|
parsedIdAttribute: function () {
|
|
|
|
return false;
|
|
|
|
},
|
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// Ghost option handling - get permitted attributes from server/data/schema.js, where the DB schema is defined
|
2015-06-14 18:58:49 +03:00
|
|
|
permittedAttributes: function permittedAttributes() {
|
2020-12-11 21:45:35 +03:00
|
|
|
return _.keys(schema.tables[this.tableName])
|
|
|
|
.filter(key => key.indexOf('@@') === -1);
|
2014-02-19 17:57:26 +04:00
|
|
|
},
|
|
|
|
|
2020-09-08 07:15:47 +03:00
|
|
|
// Ghost ordering handling, allows to order by permitted attributes by default and can be overriden on specific model level
|
|
|
|
orderAttributes: function orderAttributes() {
|
2020-09-24 04:32:40 +03:00
|
|
|
return Object.keys(schema.tables[this.tableName])
|
2020-12-11 21:45:35 +03:00
|
|
|
.map(key => `${this.tableName}.${key}`)
|
|
|
|
.filter(key => key.indexOf('@@') === -1);
|
2020-09-08 07:15:47 +03:00
|
|
|
},
|
|
|
|
|
2019-08-21 21:26:35 +03:00
|
|
|
// When loading an instance, subclasses can specify default to fetch
|
|
|
|
defaultColumnsToFetch: function defaultColumnsToFetch() {
|
|
|
|
return [];
|
|
|
|
},
|
|
|
|
|
2018-04-06 20:10:59 +03:00
|
|
|
/**
|
|
|
|
* @NOTE
|
|
|
|
* We have to remember the `_previousAttributes` attributes, because when destroying resources
|
|
|
|
* We listen on the `onDestroyed` event and Bookshelf resets these properties right after the event.
|
|
|
|
* If the query runs in a txn, `_previousAttributes` will be empty.
|
|
|
|
*/
|
2018-04-06 19:19:45 +03:00
|
|
|
emitChange: function (model, event, options) {
|
2020-10-20 02:02:56 +03:00
|
|
|
const _emit = (ghostEvent, _model, opts) => {
|
|
|
|
if (!_model.wasChanged()) {
|
2019-02-02 22:18:27 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
debug(_model.tableName, ghostEvent);
|
2019-01-29 21:44:52 +03:00
|
|
|
|
|
|
|
// @NOTE: Internal Ghost events. These are very granular e.g. post.published
|
2020-10-20 02:02:56 +03:00
|
|
|
events.emit(ghostEvent, _model, opts);
|
2019-01-29 21:44:52 +03:00
|
|
|
};
|
2019-02-02 22:18:27 +03:00
|
|
|
|
2019-01-29 21:44:52 +03:00
|
|
|
if (!options.transacting) {
|
|
|
|
return _emit(event, model, options);
|
2018-04-06 19:19:45 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (!model.ghostEvents) {
|
|
|
|
model.ghostEvents = [];
|
|
|
|
|
2018-07-24 15:37:17 +03:00
|
|
|
// CASE: when importing, deleting or migrating content, lot's of model queries are happening in one transaction
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
// lot's of model events will be triggered. we ensure we set the max listeners to infinity.
|
|
|
|
// we are using `once` - we auto remove the listener afterwards
|
2018-07-24 15:37:17 +03:00
|
|
|
if (options.importing || options.destroyAll || options.migrating) {
|
2018-04-06 19:19:45 +03:00
|
|
|
options.transacting.setMaxListeners(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
options.transacting.once('committed', (committed) => {
|
|
|
|
if (!committed) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2019-02-26 00:52:57 +03:00
|
|
|
_.each(this.ghostEvents, (obj) => {
|
|
|
|
_emit(obj.event, model, obj.options);
|
2018-04-06 19:19:45 +03:00
|
|
|
});
|
2018-04-06 20:10:59 +03:00
|
|
|
|
|
|
|
delete model.ghostEvents;
|
2018-04-06 19:19:45 +03:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2019-02-26 00:52:57 +03:00
|
|
|
model.ghostEvents.push({
|
|
|
|
event: event,
|
|
|
|
options: {
|
|
|
|
importing: options.importing,
|
|
|
|
context: options.context
|
|
|
|
}
|
|
|
|
});
|
2018-04-06 19:19:45 +03:00
|
|
|
},
|
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// Bookshelf `initialize` - declare a constructor-like method for model creation
|
2015-06-14 18:58:49 +03:00
|
|
|
initialize: function initialize() {
|
2020-04-29 18:44:27 +03:00
|
|
|
const self = this;
|
2014-04-27 20:58:34 +04:00
|
|
|
|
2018-03-19 18:27:06 +03:00
|
|
|
// NOTE: triggered before `creating`/`updating`
|
|
|
|
this.on('saving', function onSaving(newObj, attrs, options) {
|
|
|
|
if (options.method === 'insert') {
|
|
|
|
// id = 0 is still a valid value for external usage
|
|
|
|
if (_.isUndefined(newObj.id) || _.isNull(newObj.id)) {
|
|
|
|
newObj.setId();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
self.on('fetched', self.onFetched);
|
|
|
|
self.on('fetching', self.onFetching);
|
|
|
|
self.on('fetched:collection', self.onFetchedCollection);
|
|
|
|
self.on('fetching:collection', self.onFetchingCollection);
|
|
|
|
self.on('creating', self.onCreating);
|
|
|
|
self.on('created', self.onCreated);
|
|
|
|
self.on('updating', self.onUpdating);
|
|
|
|
self.on('updated', self.onUpdated);
|
|
|
|
self.on('destroying', self.onDestroying);
|
|
|
|
self.on('destroyed', self.onDestroyed);
|
|
|
|
self.on('saving', self.onSaving);
|
|
|
|
self.on('saved', self.onSaved);
|
2016-10-14 15:37:01 +03:00
|
|
|
|
2019-02-02 12:24:53 +03:00
|
|
|
// @NOTE: Please keep here. If we don't initialize the parent, bookshelf-relations won't work.
|
2017-11-21 16:28:05 +03:00
|
|
|
proto.initialize.call(this);
|
2014-02-19 17:57:26 +04:00
|
|
|
},
|
|
|
|
|
2021-03-23 12:11:24 +03:00
|
|
|
/**
|
|
|
|
* Bookshelf's .format() is run when fetching as well as saving.
|
|
|
|
* We need a way to transform attributes only on save so we override
|
|
|
|
* .sync() which is run on every database operation where we can
|
|
|
|
* run any transforms needed only on insert and update operations
|
|
|
|
*/
|
|
|
|
sync: function sync() {
|
|
|
|
const parentSync = proto.sync.apply(this, arguments);
|
|
|
|
const originalUpdateSync = parentSync.update;
|
|
|
|
const originalInsertSync = parentSync.insert;
|
|
|
|
const self = this;
|
|
|
|
|
|
|
|
// deep clone attrs to avoid modifying underlying model attributes by reference
|
|
|
|
parentSync.update = function update(attrs) {
|
|
|
|
attrs = self.formatOnWrite(_.cloneDeep(attrs));
|
|
|
|
return originalUpdateSync.apply(this, [attrs]);
|
|
|
|
};
|
|
|
|
|
|
|
|
parentSync.insert = function insert(attrs) {
|
|
|
|
attrs = self.formatOnWrite(_.cloneDeep(attrs));
|
|
|
|
return originalInsertSync.apply(this, [attrs]);
|
|
|
|
};
|
|
|
|
|
|
|
|
return parentSync;
|
|
|
|
},
|
|
|
|
|
2018-02-16 02:49:15 +03:00
|
|
|
/**
|
|
|
|
* Do not call `toJSON`. This can remove properties e.g. password.
|
|
|
|
* @returns {*}
|
|
|
|
*/
|
|
|
|
onValidate: function onValidate(model, columns, options) {
|
2018-03-05 11:10:27 +03:00
|
|
|
this.setEmptyValuesToNull();
|
2021-06-15 13:45:37 +03:00
|
|
|
return schema.validate(this.tableName, this, options);
|
2013-09-14 23:01:46 +04:00
|
|
|
},
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onFetched() {},
|
|
|
|
|
2017-11-14 02:18:59 +03:00
|
|
|
/**
|
|
|
|
* http://knexjs.org/#Builder-forUpdate
|
|
|
|
* https://dev.mysql.com/doc/refman/5.7/en/innodb-locking-reads.html
|
|
|
|
*
|
|
|
|
* Lock target collection/model for further update operations.
|
|
|
|
* This avoids collisions and possible content override cases.
|
|
|
|
*/
|
|
|
|
onFetching: function onFetching(model, columns, options) {
|
|
|
|
if (options.forUpdate && options.transacting) {
|
|
|
|
options.query.forUpdate();
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onFetchedCollection() {},
|
|
|
|
|
2017-11-14 02:18:59 +03:00
|
|
|
onFetchingCollection: function onFetchingCollection(model, columns, options) {
|
|
|
|
if (options.forUpdate && options.transacting) {
|
|
|
|
options.query.forUpdate();
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onCreated(model, attrs, options) {
|
|
|
|
addAction(model, 'added', options);
|
2018-03-19 18:27:06 +03:00
|
|
|
},
|
|
|
|
|
2017-09-28 15:59:42 +03:00
|
|
|
/**
|
|
|
|
* Adding resources implies setting these properties on the server side
|
|
|
|
* - set `created_by` based on the context
|
|
|
|
* - set `updated_by` based on the context
|
|
|
|
* - the bookshelf `timestamps` plugin sets `created_at` and `updated_at`
|
|
|
|
* - if plugin is disabled (e.g. import) we have a fallback condition
|
|
|
|
*
|
|
|
|
* Exceptions: internal context or importing
|
|
|
|
*/
|
2019-02-06 21:57:09 +03:00
|
|
|
onCreating: function onCreating(model, attr, options) {
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'created_by')) {
|
2017-09-28 15:59:42 +03:00
|
|
|
if (!options.importing || (options.importing && !this.get('created_by'))) {
|
2019-02-24 00:00:24 +03:00
|
|
|
this.set('created_by', String(this.contextUser(options)));
|
2017-09-28 15:59:42 +03:00
|
|
|
}
|
2013-09-14 23:01:46 +04:00
|
|
|
}
|
2017-05-23 19:18:13 +03:00
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'updated_by')) {
|
2018-03-19 18:27:06 +03:00
|
|
|
if (!options.importing) {
|
2019-02-24 00:00:24 +03:00
|
|
|
this.set('updated_by', String(this.contextUser(options)));
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2018-01-28 15:13:11 +03:00
|
|
|
}
|
2017-09-28 15:59:42 +03:00
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'created_at')) {
|
2019-02-06 21:57:09 +03:00
|
|
|
if (!model.get('created_at')) {
|
|
|
|
model.set('created_at', new Date());
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2017-05-23 19:18:13 +03:00
|
|
|
}
|
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'updated_at')) {
|
2019-02-06 21:57:09 +03:00
|
|
|
if (!model.get('updated_at')) {
|
|
|
|
model.set('updated_at', new Date());
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2017-05-23 19:18:13 +03:00
|
|
|
}
|
2013-09-14 23:01:46 +04:00
|
|
|
|
2019-02-07 22:01:47 +03:00
|
|
|
return Promise.resolve(this.onValidate(model, attr, options))
|
|
|
|
.then(() => {
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
*
|
|
|
|
* The API requires only specific attributes to send. If we don't set the rest explicitly to null,
|
|
|
|
* we end up in a situation that on "created" events the field set is incomplete, which is super confusing
|
|
|
|
* and hard to work with if you trigger internal events, which rely on full field set. This ensures consistency.
|
|
|
|
*
|
|
|
|
* @NOTE:
|
|
|
|
*
|
|
|
|
* Happens after validation to ensure we don't set fields which are not nullable on db level.
|
|
|
|
*/
|
2020-12-11 21:45:35 +03:00
|
|
|
_.each(Object.keys(schema.tables[this.tableName]).filter(key => key.indexOf('@@') === -1), (columnKey) => {
|
2019-02-07 22:01:47 +03:00
|
|
|
if (model.get(columnKey) === undefined) {
|
|
|
|
model.set(columnKey, null);
|
|
|
|
}
|
|
|
|
});
|
2019-02-06 21:57:09 +03:00
|
|
|
|
2019-02-07 22:01:47 +03:00
|
|
|
model._changed = _.cloneDeep(model.changed);
|
|
|
|
});
|
2017-09-28 15:59:42 +03:00
|
|
|
},
|
2014-04-22 05:04:30 +04:00
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onUpdated(model, attrs, options) {
|
|
|
|
addAction(model, 'edited', options);
|
|
|
|
},
|
|
|
|
|
2017-09-28 15:59:42 +03:00
|
|
|
/**
|
|
|
|
* Changing resources implies setting these properties on the server side
|
|
|
|
* - set `updated_by` based on the context
|
|
|
|
* - ensure `created_at` never changes
|
|
|
|
* - ensure `created_by` never changes
|
|
|
|
* - the bookshelf `timestamps` plugin sets `updated_at` automatically
|
|
|
|
*
|
|
|
|
* Exceptions:
|
|
|
|
* - importing data
|
|
|
|
* - internal context
|
|
|
|
* - if no context
|
2019-01-03 19:14:52 +03:00
|
|
|
*
|
|
|
|
* @deprecated: x_by fields (https://github.com/TryGhost/Ghost/issues/10286)
|
2017-09-28 15:59:42 +03:00
|
|
|
*/
|
2019-02-02 12:24:53 +03:00
|
|
|
onUpdating: function onUpdating(model, attr, options) {
|
|
|
|
if (this.relationships) {
|
|
|
|
model.changed = _.omit(model.changed, this.relationships);
|
|
|
|
}
|
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'updated_by')) {
|
2018-08-22 14:57:12 +03:00
|
|
|
if (!options.importing && !options.migrating) {
|
2019-02-24 00:00:24 +03:00
|
|
|
this.set('updated_by', String(this.contextUser(options)));
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2018-01-28 15:13:11 +03:00
|
|
|
}
|
2017-09-28 15:59:42 +03:00
|
|
|
|
2019-02-02 12:24:53 +03:00
|
|
|
if (options && options.context && !options.context.internal && !options.importing) {
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'created_at')) {
|
2019-02-02 12:24:53 +03:00
|
|
|
if (model.hasDateChanged('created_at', {beforeWrite: true})) {
|
|
|
|
model.set('created_at', this.previous('created_at'));
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2017-09-28 15:59:42 +03:00
|
|
|
}
|
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'created_by')) {
|
2019-02-02 12:24:53 +03:00
|
|
|
if (model.hasChanged('created_by')) {
|
2019-02-24 00:00:24 +03:00
|
|
|
model.set('created_by', String(this.previous('created_by')));
|
2018-03-19 18:27:06 +03:00
|
|
|
}
|
2017-09-28 15:59:42 +03:00
|
|
|
}
|
|
|
|
}
|
2018-03-19 18:27:06 +03:00
|
|
|
|
2018-04-05 17:25:49 +03:00
|
|
|
// CASE: do not allow setting only the `updated_at` field, exception: importing
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[this.tableName], 'updated_at') && !options.importing) {
|
2018-08-22 14:57:12 +03:00
|
|
|
if (options.migrating) {
|
2019-02-02 12:24:53 +03:00
|
|
|
model.set('updated_at', model.previous('updated_at'));
|
|
|
|
} else if (Object.keys(model.changed).length === 1 && model.changed.updated_at) {
|
|
|
|
model.set('updated_at', model.previous('updated_at'));
|
|
|
|
delete model.changed.updated_at;
|
2018-04-05 17:25:49 +03:00
|
|
|
}
|
2018-03-26 16:12:02 +03:00
|
|
|
}
|
|
|
|
|
2019-02-02 12:24:53 +03:00
|
|
|
model._changed = _.cloneDeep(model.changed);
|
|
|
|
|
|
|
|
return Promise.resolve(this.onValidate(model, attr, options));
|
2013-09-14 23:01:46 +04:00
|
|
|
},
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onSaved() {},
|
2019-02-07 00:05:03 +03:00
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onSaving: function onSaving() {
|
|
|
|
// Remove any properties which don't belong on the model
|
|
|
|
this.attributes = this.pick(this.permittedAttributes());
|
2019-02-07 00:05:03 +03:00
|
|
|
},
|
|
|
|
|
2019-08-14 05:32:45 +03:00
|
|
|
onDestroying() {},
|
|
|
|
|
2019-02-07 00:05:03 +03:00
|
|
|
onDestroyed(model, options) {
|
2019-02-07 13:10:26 +03:00
|
|
|
if (!model._changed) {
|
|
|
|
model._changed = {};
|
|
|
|
}
|
|
|
|
|
|
|
|
// @NOTE: Bookshelf destroys ".changed" right after this event, but we should not throw away the information
|
|
|
|
// It is useful for webhooks, events etc.
|
|
|
|
// @NOTE: Bookshelf returns ".changed = {empty...}" on destroying (https://github.com/bookshelf/bookshelf/issues/1943)
|
|
|
|
Object.assign(model._changed, _.cloneDeep(model.changed));
|
|
|
|
|
2019-02-07 00:05:03 +03:00
|
|
|
addAction(model, 'deleted', options);
|
|
|
|
},
|
|
|
|
|
2016-06-03 11:06:18 +03:00
|
|
|
/**
|
|
|
|
* before we insert dates into the database, we have to normalize
|
|
|
|
* date format is now in each db the same
|
|
|
|
*/
|
|
|
|
fixDatesWhenSave: function fixDates(attrs) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const self = this;
|
2014-07-05 18:57:56 +04:00
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
_.each(attrs, function each(value, key) {
|
2014-07-24 12:17:10 +04:00
|
|
|
if (value !== null
|
2019-07-05 14:40:43 +03:00
|
|
|
&& Object.prototype.hasOwnProperty.call(schema.tables[self.tableName], key)
|
2017-04-19 16:53:23 +03:00
|
|
|
&& schema.tables[self.tableName][key].type === 'dateTime') {
|
2016-06-03 11:06:18 +03:00
|
|
|
attrs[key] = moment(value).format('YYYY-MM-DD HH:mm:ss');
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return attrs;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2017-09-26 19:16:46 +03:00
|
|
|
* all supported databases (sqlite, mysql) return different values
|
2016-06-03 11:06:18 +03:00
|
|
|
*
|
|
|
|
* sqlite:
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
* - knex returns a UTC String (2018-04-12 20:50:35)
|
2016-06-03 11:06:18 +03:00
|
|
|
* mysql:
|
|
|
|
* - knex wraps the UTC value into a local JS Date
|
|
|
|
*/
|
|
|
|
fixDatesWhenFetch: function fixDates(attrs) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const self = this;
|
|
|
|
let dateMoment;
|
2016-06-03 11:06:18 +03:00
|
|
|
|
|
|
|
_.each(attrs, function each(value, key) {
|
|
|
|
if (value !== null
|
2019-07-05 14:40:43 +03:00
|
|
|
&& Object.prototype.hasOwnProperty.call(schema.tables[self.tableName], key)
|
2016-06-03 11:06:18 +03:00
|
|
|
&& schema.tables[self.tableName][key].type === 'dateTime') {
|
2017-10-04 11:56:09 +03:00
|
|
|
dateMoment = moment(value);
|
|
|
|
|
|
|
|
// CASE: You are somehow able to store e.g. 0000-00-00 00:00:00
|
|
|
|
// Protect the code base and return the current date time.
|
|
|
|
if (dateMoment.isValid()) {
|
|
|
|
attrs[key] = dateMoment.startOf('seconds').toDate();
|
|
|
|
} else {
|
|
|
|
attrs[key] = moment().startOf('seconds').toDate();
|
|
|
|
}
|
2013-07-08 15:39:11 +04:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return attrs;
|
|
|
|
},
|
|
|
|
|
2014-04-25 11:55:53 +04:00
|
|
|
// Convert integers to real booleans
|
2015-06-14 18:58:49 +03:00
|
|
|
fixBools: function fixBools(attrs) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const self = this;
|
2015-06-14 18:58:49 +03:00
|
|
|
_.each(attrs, function each(value, key) {
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(schema.tables[self.tableName], key)
|
2017-04-19 16:53:23 +03:00
|
|
|
&& schema.tables[self.tableName][key].type === 'bool') {
|
2014-04-25 11:55:53 +04:00
|
|
|
attrs[key] = value ? true : false;
|
2014-01-05 02:16:29 +04:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return attrs;
|
|
|
|
},
|
|
|
|
|
2019-01-28 18:58:28 +03:00
|
|
|
getNullableStringProperties() {
|
|
|
|
const table = schema.tables[this.tableName];
|
|
|
|
return Object.keys(table).filter(column => table[column].nullable);
|
|
|
|
},
|
2018-03-05 11:10:27 +03:00
|
|
|
|
2019-01-28 18:58:28 +03:00
|
|
|
setEmptyValuesToNull: function setEmptyValuesToNull() {
|
|
|
|
const nullableStringProps = this.getNullableStringProperties();
|
|
|
|
return nullableStringProps.forEach((prop) => {
|
|
|
|
if (this.get(prop) === '') {
|
|
|
|
this.set(prop, null);
|
2018-03-05 11:10:27 +03:00
|
|
|
}
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
2019-01-29 21:44:52 +03:00
|
|
|
getActor(options = {context: {}}) {
|
2019-02-06 22:14:36 +03:00
|
|
|
if (options.context && options.context.integration) {
|
2019-01-29 21:44:52 +03:00
|
|
|
return {
|
2019-02-06 22:11:44 +03:00
|
|
|
id: options.context.integration.id,
|
2019-01-29 21:44:52 +03:00
|
|
|
type: 'integration'
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
2019-02-06 22:14:36 +03:00
|
|
|
if (options.context && options.context.user) {
|
2019-01-29 21:44:52 +03:00
|
|
|
return {
|
|
|
|
id: options.context.user,
|
|
|
|
type: 'user'
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
return null;
|
|
|
|
},
|
|
|
|
|
2014-07-15 15:03:12 +04:00
|
|
|
// Get the user from the options object
|
2015-06-14 18:58:49 +03:00
|
|
|
contextUser: function contextUser(options) {
|
2016-11-09 18:01:07 +03:00
|
|
|
options = options || {};
|
|
|
|
options.context = options.context || {};
|
|
|
|
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
if (options.context.user || ghostBookshelf.Model.isExternalUser(options.context.user)) {
|
2014-07-15 15:03:12 +04:00
|
|
|
return options.context.user;
|
2019-01-21 14:41:45 +03:00
|
|
|
} else if (options.context.integration) {
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
*
|
|
|
|
* This is a dirty hotfix for v0.1 only.
|
|
|
|
* The `x_by` columns are getting deprecated soon (https://github.com/TryGhost/Ghost/issues/10286).
|
|
|
|
*
|
|
|
|
* We return the owner ID '1' in case an integration updates or creates
|
|
|
|
* resources. v0.1 will continue to use the `x_by` columns. v0.1 does not support integrations.
|
|
|
|
* API v2 will introduce a new feature to solve inserting/updating resources
|
|
|
|
* from users or integrations. API v2 won't expose `x_by` columns anymore.
|
|
|
|
*
|
|
|
|
* ---
|
|
|
|
*
|
|
|
|
* Why using ID '1'? WAIT. What???????
|
|
|
|
*
|
|
|
|
* See https://github.com/TryGhost/Ghost/issues/9299.
|
|
|
|
*
|
|
|
|
* We currently don't read the correct owner ID from the database and assume it's '1'.
|
|
|
|
* This is a leftover from switching from auto increment ID's to Object ID's.
|
|
|
|
* But this takes too long to refactor out now. If an internal update happens, we also
|
|
|
|
* use ID '1'. This logic exists for a LONG while now. The owner ID only changes from '1' to something else,
|
|
|
|
* if you transfer ownership.
|
|
|
|
*/
|
|
|
|
return ghostBookshelf.Model.internalUser;
|
2016-11-09 18:01:07 +03:00
|
|
|
} else if (options.context.internal) {
|
|
|
|
return ghostBookshelf.Model.internalUser;
|
|
|
|
} else if (this.get('id')) {
|
|
|
|
return this.get('id');
|
|
|
|
} else if (options.context.external) {
|
|
|
|
return ghostBookshelf.Model.externalUser;
|
2014-07-15 15:03:12 +04:00
|
|
|
} else {
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.NotFoundError({
|
2021-06-14 19:18:25 +03:00
|
|
|
message: tpl(messages.missingContext),
|
2016-10-06 15:27:35 +03:00
|
|
|
level: 'critical'
|
|
|
|
});
|
2014-07-15 15:03:12 +04:00
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2014-04-25 11:55:53 +04:00
|
|
|
// format date before writing to DB, bools work
|
2015-06-14 18:58:49 +03:00
|
|
|
format: function format(attrs) {
|
2016-06-03 11:06:18 +03:00
|
|
|
return this.fixDatesWhenSave(attrs);
|
2014-04-25 11:55:53 +04:00
|
|
|
},
|
|
|
|
|
2021-03-23 12:11:24 +03:00
|
|
|
// overridable function for models to format attrs only when saving to db
|
|
|
|
formatOnWrite: function formatOnWrite(attrs) {
|
|
|
|
return attrs;
|
|
|
|
},
|
|
|
|
|
2014-04-25 11:55:53 +04:00
|
|
|
// format data and bool when fetching from DB
|
2015-06-14 18:58:49 +03:00
|
|
|
parse: function parse(attrs) {
|
2016-06-03 11:06:18 +03:00
|
|
|
return this.fixBools(this.fixDatesWhenFetch(attrs));
|
2013-07-08 15:39:11 +04:00
|
|
|
},
|
|
|
|
|
2018-02-14 19:32:11 +03:00
|
|
|
/**
|
|
|
|
* `shallow` - won't return relations
|
|
|
|
* `omitPivot` - won't return pivot fields
|
|
|
|
*
|
|
|
|
* `toJSON` calls `serialize`.
|
|
|
|
*
|
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
|
|
|
* @param unfilteredOptions
|
2018-02-14 19:32:11 +03:00
|
|
|
* @returns {*}
|
|
|
|
*/
|
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
|
|
|
toJSON: function toJSON(unfilteredOptions) {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
const options = ghostBookshelf.Model.filterOptions(unfilteredOptions, 'toJSON');
|
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
|
|
|
options.omitPivot = true;
|
2013-07-08 15:39:11 +04:00
|
|
|
|
2019-09-16 11:45:55 +03:00
|
|
|
/**
|
|
|
|
* removes null relations coming from `hasOne` - https://bookshelfjs.org/api.html#Model-instance-hasOne
|
|
|
|
* Based on https://github.com/bookshelf/bookshelf/issues/72#issuecomment-25164617
|
|
|
|
*/
|
|
|
|
_.each(this.relations, (value, key) => {
|
|
|
|
if (_.isEmpty(value)) {
|
|
|
|
delete this.relations[key];
|
|
|
|
}
|
|
|
|
});
|
2019-02-26 01:35:52 +03:00
|
|
|
// CASE: get JSON of previous attrs
|
2019-02-03 16:18:46 +03:00
|
|
|
if (options.previous) {
|
2019-02-26 01:35:52 +03:00
|
|
|
const clonedModel = _.cloneDeep(this);
|
|
|
|
clonedModel.attributes = this._previousAttributes;
|
2019-02-03 16:18:46 +03:00
|
|
|
|
2019-02-26 01:35:52 +03:00
|
|
|
if (this.relationships) {
|
|
|
|
this.relationships.forEach((relation) => {
|
2019-07-05 14:40:43 +03:00
|
|
|
if (this._previousRelations && Object.prototype.hasOwnProperty.call(this._previousRelations, relation)) {
|
2019-02-26 01:35:52 +03:00
|
|
|
clonedModel.related(relation).models = this._previousRelations[relation].models;
|
|
|
|
}
|
2019-02-03 15:36:08 +03:00
|
|
|
});
|
|
|
|
}
|
2019-02-03 16:18:46 +03:00
|
|
|
|
2019-02-26 01:35:52 +03:00
|
|
|
return proto.toJSON.call(clonedModel, options);
|
2019-02-03 16:18:46 +03:00
|
|
|
}
|
|
|
|
|
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 proto.toJSON.call(this, options);
|
2013-09-14 23:01:46 +04:00
|
|
|
},
|
|
|
|
|
2019-01-21 23:53:11 +03:00
|
|
|
hasDateChanged: function (attr) {
|
|
|
|
return moment(this.get(attr)).diff(moment(this.previous(attr))) !== 0;
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* we auto generate a GUID for each resource
|
|
|
|
* no auto increment
|
|
|
|
*/
|
|
|
|
setId: function setId() {
|
2021-04-21 18:02:02 +03:00
|
|
|
this.set('id', ObjectId().toHexString());
|
2019-02-08 00:05:07 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
wasChanged() {
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* Not every model & interaction is currently set up to handle "._changed".
|
|
|
|
* e.g. we trigger a manual event for "tag.attached", where as "._changed" is undefined.
|
|
|
|
*
|
|
|
|
* Keep "true" till we are sure that "._changed" is always a thing.
|
|
|
|
*/
|
|
|
|
if (!this._changed) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!Object.keys(this._changed).length) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
2013-07-08 15:39:11 +04:00
|
|
|
}
|
2013-06-25 15:43:15 +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
|
|
|
// ## Data Utility Functions
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
|
2016-11-09 18:01:07 +03:00
|
|
|
/**
|
|
|
|
* please use these static definitions when comparing id's
|
2017-07-31 12:37:37 +03:00
|
|
|
* we keep type Number, because we have too many check's where we rely on Number
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
* context.user ? true : false (if context.user is 0 as number, this condition is false)
|
2016-11-09 18:01:07 +03:00
|
|
|
*/
|
|
|
|
internalUser: 1,
|
|
|
|
externalUser: 0,
|
|
|
|
|
|
|
|
isInternalUser: function isInternalUser(id) {
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
return id === ghostBookshelf.Model.internalUser || id === ghostBookshelf.Model.internalUser.toString();
|
2016-11-09 18:01:07 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
isExternalUser: function isExternalUser(id) {
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
return id === ghostBookshelf.Model.externalUser || id === ghostBookshelf.Model.externalUser.toString();
|
2016-11-09 18:01:07 +03:00
|
|
|
},
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
/**
|
|
|
|
* Returns an array of keys permitted in every method's `options` hash.
|
|
|
|
* Can be overridden and added to by a model's `permittedOptions` method.
|
2016-06-03 11:06:18 +03:00
|
|
|
*
|
|
|
|
* importing: is used when import a JSON file or when migrating the database
|
|
|
|
*
|
2015-10-10 19:07:10 +03:00
|
|
|
* @return {Object} Keys allowed in the `options` hash of every model's method.
|
2014-05-06 05:45:08 +04:00
|
|
|
*/
|
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
|
|
|
permittedOptions: function permittedOptions(methodName) {
|
2018-09-20 15:58:57 +03:00
|
|
|
const baseOptions = ['context', 'withRelated'];
|
|
|
|
const extraOptions = ['transacting', 'importing', 'forUpdate', 'migrating'];
|
|
|
|
|
|
|
|
switch (methodName) {
|
|
|
|
case 'toJSON':
|
2019-02-03 16:18:46 +03:00
|
|
|
return baseOptions.concat('shallow', 'columns', 'previous');
|
2018-09-20 15:58:57 +03:00
|
|
|
case 'destroy':
|
2018-10-12 14:00:21 +03:00
|
|
|
return baseOptions.concat(extraOptions, ['id', 'destroyBy', 'require']);
|
2018-09-20 15:58:57 +03:00
|
|
|
case 'edit':
|
2018-10-12 14:00:21 +03:00
|
|
|
return baseOptions.concat(extraOptions, ['id', 'require']);
|
|
|
|
case 'findOne':
|
2019-09-16 13:51:54 +03:00
|
|
|
return baseOptions.concat(extraOptions, ['columns', 'require', 'mongoTransformer']);
|
2018-10-12 20:56:50 +03:00
|
|
|
case 'findAll':
|
2019-10-09 17:04:09 +03:00
|
|
|
return baseOptions.concat(extraOptions, ['filter', 'columns', 'mongoTransformer']);
|
2019-01-30 00:57:11 +03:00
|
|
|
case 'findPage':
|
Updated Content API resource ordering to be same as slugs in filter
closes #11994
- Adds support for ordering based on slug filter that contains a slug-is-in filter. It is applied only to Content API's resources - post, page, tag, author. The order is applied in the same order in which slugs appear in the filter.
- For, example providing following query parameter filter for any of the above resources: `?filter=slug:[kitchen-sink,bacon,chorizo]`, would filter them by these slugs and order in the same way defined in the filter
- Can be used in handlebars templates in following way: `{{#get "tags" filter="slug:[slugs,of,the,tags,in,order]"}}`
- The property conteining this new order is assigned to `autoOrder` instead of `rawOrder` intentionally. This explicit asstignment would allow distinguishing where the 'orderRaw' comes from the model or the API layer. Apart from adding necessary context this separation makes it easier to refactor separately model layer and API specific ordering in the future
- This commit also fixes default filtering for `author` resource in Content API. The serializer was never used before as it was missing from `serializers/index.js` module.
2020-07-10 09:33:00 +03:00
|
|
|
return baseOptions.concat(extraOptions, ['filter', 'order', 'autoOrder', 'page', 'limit', 'columns', 'mongoTransformer']);
|
2018-09-20 15:58:57 +03:00
|
|
|
default:
|
|
|
|
return baseOptions.concat(extraOptions);
|
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
|
|
|
}
|
2014-05-06 05:45:08 +04:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Filters potentially unsafe model attributes, so you can pass them to Bookshelf / Knex.
|
2017-04-19 11:59:09 +03:00
|
|
|
* This filter should be called before each insert/update operation.
|
|
|
|
*
|
2014-05-06 05:45:08 +04:00
|
|
|
* @param {Object} data Has keys representing the model's attributes/fields in the database.
|
|
|
|
* @return {Object} The filtered results of the passed in data, containing only what's allowed in the schema.
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
filterData: function filterData(data) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const permittedAttributes = this.prototype.permittedAttributes();
|
|
|
|
const filteredData = _.pick(data, permittedAttributes);
|
|
|
|
const sanitizedData = this.sanitizeData(filteredData);
|
2017-04-19 11:59:09 +03:00
|
|
|
|
|
|
|
return sanitizedData;
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* `sanitizeData` ensures that client data is in the correct format for further operations.
|
|
|
|
*
|
|
|
|
* Dates:
|
2017-07-20 13:24:23 +03:00
|
|
|
* - client dates are sent as ISO 8601 format (moment(..).format())
|
2017-04-19 11:59:09 +03:00
|
|
|
* - server dates are in JS Date format
|
|
|
|
* >> when bookshelf fetches data from the database, all dates are in JS Dates
|
|
|
|
* >> see `parse`
|
|
|
|
* - Bookshelf updates the model with the new client data via the `set` function
|
|
|
|
* - Bookshelf uses a simple `isEqual` function from lodash to detect real changes
|
|
|
|
* - .previous(attr) and .get(attr) returns false obviously
|
2019-01-21 23:53:11 +03:00
|
|
|
* - internally we use our `hasDateChanged` if we have to compare previous dates
|
2017-04-19 11:59:09 +03:00
|
|
|
* - but Bookshelf is not in our control for this case
|
|
|
|
*
|
|
|
|
* @IMPORTANT
|
2017-12-14 19:04:06 +03:00
|
|
|
* Before the new client data get's inserted again, the dates get's re-transformed into
|
2017-04-19 11:59:09 +03:00
|
|
|
* proper strings, see `format`.
|
2018-04-05 17:11:47 +03:00
|
|
|
*
|
|
|
|
* @IMPORTANT
|
|
|
|
* Sanitize relations.
|
2017-04-19 11:59:09 +03:00
|
|
|
*/
|
|
|
|
sanitizeData: function sanitizeData(data) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const tableName = _.result(this.prototype, 'tableName');
|
|
|
|
let date;
|
2017-04-19 11:59:09 +03:00
|
|
|
|
2018-04-05 17:11:47 +03:00
|
|
|
_.each(data, (value, property) => {
|
2017-04-19 11:59:09 +03:00
|
|
|
if (value !== null
|
2019-07-05 14:40:43 +03:00
|
|
|
&& Object.prototype.hasOwnProperty.call(schema.tables[tableName], property)
|
2018-04-05 17:11:47 +03:00
|
|
|
&& schema.tables[tableName][property].type === 'dateTime'
|
2017-04-19 11:59:09 +03:00
|
|
|
&& typeof value === 'string'
|
|
|
|
) {
|
2017-12-14 19:04:06 +03:00
|
|
|
date = new Date(value);
|
2017-10-04 11:56:09 +03:00
|
|
|
|
|
|
|
// CASE: client sends `0000-00-00 00:00:00`
|
2017-12-14 19:04:06 +03:00
|
|
|
if (isNaN(date)) {
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.ValidationError({
|
2021-06-14 19:18:25 +03:00
|
|
|
message: tpl(messages.invalidDate, {key: property}),
|
2017-12-14 19:04:06 +03:00
|
|
|
code: 'DATE_INVALID'
|
2017-10-04 11:56:09 +03:00
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2018-04-05 17:11:47 +03:00
|
|
|
data[property] = moment(value).toDate();
|
|
|
|
}
|
|
|
|
|
|
|
|
if (this.prototype.relationships && this.prototype.relationships.indexOf(property) !== -1) {
|
2019-09-16 11:45:55 +03:00
|
|
|
let relations = data[property];
|
|
|
|
|
|
|
|
// CASE: 1:1 relation will have single data point
|
|
|
|
if (!_.isArray(data[property])) {
|
|
|
|
relations = [data[property]];
|
|
|
|
}
|
|
|
|
_.each(relations, (relation, indexInArr) => {
|
2020-10-20 02:02:56 +03:00
|
|
|
_.each(relation, (relationValue, relationProperty) => {
|
|
|
|
if (relationValue !== null
|
2019-07-05 14:40:43 +03:00
|
|
|
&& Object.prototype.hasOwnProperty.call(schema.tables[this.prototype.relationshipBelongsTo[property]], relationProperty)
|
2018-04-05 17:11:47 +03:00
|
|
|
&& schema.tables[this.prototype.relationshipBelongsTo[property]][relationProperty].type === 'dateTime'
|
2020-10-20 02:02:56 +03:00
|
|
|
&& typeof relationValue === 'string'
|
2018-04-05 17:11:47 +03:00
|
|
|
) {
|
2020-10-20 02:02:56 +03:00
|
|
|
date = new Date(relationValue);
|
2018-04-05 17:11:47 +03:00
|
|
|
|
|
|
|
// CASE: client sends `0000-00-00 00:00:00`
|
|
|
|
if (isNaN(date)) {
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.ValidationError({
|
2021-06-14 19:18:25 +03:00
|
|
|
message: tpl(messages.invalidDate, {key: relationProperty}),
|
2018-04-05 17:11:47 +03:00
|
|
|
code: 'DATE_INVALID'
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
data[property][indexInArr][relationProperty] = moment(relationValue).toDate();
|
2018-04-05 17:11:47 +03:00
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
2017-04-19 11:59:09 +03:00
|
|
|
}
|
|
|
|
});
|
2014-05-06 05:45:08 +04:00
|
|
|
|
2017-04-19 11:59:09 +03:00
|
|
|
return data;
|
2014-05-06 05:45:08 +04:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Filters potentially unsafe `options` in a model method's arguments, so you can pass them to Bookshelf / Knex.
|
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
|
|
|
* @param {Object} unfilteredOptions Represents options to filter in order to be passed to the Bookshelf query.
|
2014-05-06 05:45:08 +04:00
|
|
|
* @param {String} methodName The name of the method to check valid options for.
|
|
|
|
* @return {Object} The filtered results of `options`.
|
2017-04-19 16:53:23 +03:00
|
|
|
*/
|
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
|
|
|
filterOptions: function filterOptions(unfilteredOptions, methodName, filterConfig) {
|
|
|
|
unfilteredOptions = unfilteredOptions || {};
|
|
|
|
filterConfig = filterConfig || {};
|
|
|
|
|
2019-07-05 14:40:43 +03:00
|
|
|
if (Object.prototype.hasOwnProperty.call(unfilteredOptions, 'include')) {
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.IncorrectUsageError({
|
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
|
|
|
message: 'The model layer expects using `withRelated`.'
|
|
|
|
});
|
|
|
|
}
|
2014-05-06 05:45:08 +04:00
|
|
|
|
2020-04-29 18:44:27 +03:00
|
|
|
let options = _.cloneDeep(unfilteredOptions);
|
|
|
|
const extraAllowedProperties = filterConfig.extraAllowedProperties || [];
|
|
|
|
let permittedOptions;
|
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
|
|
|
|
|
|
|
permittedOptions = this.permittedOptions(methodName, options);
|
|
|
|
permittedOptions = _.union(permittedOptions, extraAllowedProperties);
|
|
|
|
options = _.pick(options, permittedOptions);
|
|
|
|
|
2018-04-15 13:12:20 +03:00
|
|
|
if (this.defaultRelations) {
|
|
|
|
options = this.defaultRelations(methodName, 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 options;
|
2014-05-06 05:45:08 +04:00
|
|
|
},
|
|
|
|
|
2015-05-01 00:14:19 +03:00
|
|
|
// ## Model Data Functions
|
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
|
|
|
|
2020-08-27 02:41:22 +03:00
|
|
|
getFilteredCollection: function getFilteredCollection(options) {
|
|
|
|
const filteredCollection = this.forge();
|
|
|
|
|
|
|
|
// Apply model-specific query behaviour
|
|
|
|
filteredCollection.applyCustomQuery(options);
|
|
|
|
|
|
|
|
// Add Filter behaviour
|
|
|
|
filteredCollection.applyDefaultAndCustomFilters(options);
|
|
|
|
|
|
|
|
// Apply model-specific search behaviour
|
|
|
|
filteredCollection.applySearchQuery(options);
|
|
|
|
|
|
|
|
return filteredCollection;
|
|
|
|
},
|
|
|
|
|
2020-09-14 17:40:00 +03:00
|
|
|
getFilteredCollectionQuery: function getFilteredCollectionQuery(options) {
|
|
|
|
const filteredCollection = this.getFilteredCollection(options);
|
|
|
|
const filteredCollectionQuery = filteredCollection.query();
|
|
|
|
|
|
|
|
if (options.transacting) {
|
|
|
|
filteredCollectionQuery.transacting(options.transacting);
|
|
|
|
if (options.forUpdate) {
|
|
|
|
filteredCollectionQuery.forUpdate();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return filteredCollectionQuery;
|
|
|
|
},
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
/**
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* ### Find All
|
2016-04-14 18:54:49 +03:00
|
|
|
* Fetches all the data for a particular model
|
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
|
|
|
* @param {Object} unfilteredOptions (optional)
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<ghostBookshelf.Collection>} Collection of all Models
|
2013-06-25 15:43:15 +04:00
|
|
|
*/
|
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
|
|
|
findAll: function findAll(unfilteredOptions) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'findAll');
|
2020-08-27 02:41:22 +03:00
|
|
|
const itemCollection = this.getFilteredCollection(options);
|
2016-04-14 18:54:49 +03:00
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
// @TODO: we can't use order raw when running migrations (see https://github.com/tgriesser/knex/issues/2763)
|
|
|
|
if (this.orderDefaultRaw && !options.migrating) {
|
|
|
|
itemCollection.query((qb) => {
|
2018-11-15 17:27:31 +03:00
|
|
|
qb.orderByRaw(this.orderDefaultRaw(options));
|
2018-10-09 16:31:09 +03:00
|
|
|
});
|
|
|
|
}
|
2016-04-14 18:54:49 +03:00
|
|
|
|
|
|
|
return itemCollection.fetchAll(options).then(function then(result) {
|
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
|
|
|
if (options.withRelated) {
|
2015-06-14 18:58:49 +03:00
|
|
|
_.each(result.models, function each(item) {
|
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
|
|
|
item.withRelated = options.withRelated;
|
2014-04-27 20:58:34 +04:00
|
|
|
});
|
|
|
|
}
|
2016-10-12 18:18:57 +03:00
|
|
|
|
2014-04-27 20:58:34 +04:00
|
|
|
return result;
|
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
/**
|
|
|
|
* ### Find Page
|
|
|
|
* Find results by page - returns an object containing the
|
|
|
|
* information about the request (page, limit), along with the
|
|
|
|
* info needed for pagination (pages, total).
|
|
|
|
*
|
|
|
|
* **response:**
|
|
|
|
*
|
|
|
|
* {
|
2018-09-26 15:11:22 +03:00
|
|
|
* data: [
|
|
|
|
* {...}, ...
|
|
|
|
* ],
|
|
|
|
* meta: {
|
|
|
|
* pagination: {
|
|
|
|
* page: __,
|
|
|
|
* limit: __,
|
|
|
|
* pages: __,
|
|
|
|
* total: __
|
|
|
|
* }
|
|
|
|
* }
|
2015-06-17 16:55:39 +03:00
|
|
|
* }
|
|
|
|
*
|
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
|
|
|
* @param {Object} unfilteredOptions
|
2015-06-17 16:55:39 +03:00
|
|
|
*/
|
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
|
|
|
findPage: function findPage(unfilteredOptions) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'findPage');
|
2020-08-27 02:41:22 +03:00
|
|
|
const itemCollection = this.getFilteredCollection(options);
|
2020-04-29 18:44:27 +03:00
|
|
|
const requestedColumns = options.columns;
|
2015-06-17 16:55:39 +03:00
|
|
|
|
2015-11-12 17:21:04 +03:00
|
|
|
// Set this to true or pass ?debug=true as an API option to get output
|
2020-08-27 02:41:22 +03:00
|
|
|
itemCollection.debug = unfilteredOptions.debug && config.get('env') !== 'production';
|
2020-05-28 12:14:02 +03:00
|
|
|
|
2015-11-11 22:31:52 +03:00
|
|
|
// Ensure only valid fields/columns are added to query
|
2016-07-18 23:21:47 +03:00
|
|
|
// and append default columns to fetch
|
2015-11-11 22:31:52 +03:00
|
|
|
if (options.columns) {
|
|
|
|
options.columns = _.intersection(options.columns, this.prototype.permittedAttributes());
|
2019-08-21 21:26:35 +03:00
|
|
|
options.columns = _.union(options.columns, this.prototype.defaultColumnsToFetch());
|
2015-11-11 22:31:52 +03:00
|
|
|
}
|
|
|
|
|
2015-10-22 15:49:15 +03:00
|
|
|
if (options.order) {
|
2020-12-03 23:13:37 +03:00
|
|
|
const {order, orderRaw, eagerLoad} = itemCollection.parseOrderOption(options.order, options.withRelated);
|
|
|
|
options.orderRaw = orderRaw;
|
|
|
|
options.order = order;
|
|
|
|
options.eagerLoad = eagerLoad;
|
Updated Content API resource ordering to be same as slugs in filter
closes #11994
- Adds support for ordering based on slug filter that contains a slug-is-in filter. It is applied only to Content API's resources - post, page, tag, author. The order is applied in the same order in which slugs appear in the filter.
- For, example providing following query parameter filter for any of the above resources: `?filter=slug:[kitchen-sink,bacon,chorizo]`, would filter them by these slugs and order in the same way defined in the filter
- Can be used in handlebars templates in following way: `{{#get "tags" filter="slug:[slugs,of,the,tags,in,order]"}}`
- The property conteining this new order is assigned to `autoOrder` instead of `rawOrder` intentionally. This explicit asstignment would allow distinguishing where the 'orderRaw' comes from the model or the API layer. Apart from adding necessary context this separation makes it easier to refactor separately model layer and API specific ordering in the future
- This commit also fixes default filtering for `author` resource in Content API. The serializer was never used before as it was missing from `serializers/index.js` module.
2020-07-10 09:33:00 +03:00
|
|
|
} else if (options.autoOrder) {
|
|
|
|
options.orderRaw = options.autoOrder;
|
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
|
|
|
} else if (this.orderDefaultRaw) {
|
2018-11-15 17:27:31 +03:00
|
|
|
options.orderRaw = this.orderDefaultRaw(options);
|
2018-10-03 17:27:33 +03:00
|
|
|
} else if (this.orderDefaultOptions) {
|
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
|
|
|
options.order = this.orderDefaultOptions();
|
2015-10-22 15:49:15 +03:00
|
|
|
}
|
2016-07-15 13:04:10 +03:00
|
|
|
|
2015-10-24 23:39:47 +03:00
|
|
|
return itemCollection.fetchPage(options).then(function formatResponse(response) {
|
2018-09-26 15:11:22 +03:00
|
|
|
// Attributes are being filtered here, so they are not leaked into calling layer
|
|
|
|
// where models are serialized to json and do not do more filtering.
|
|
|
|
// Re-add and pick any computed properties that were stripped before fetchPage call.
|
|
|
|
const data = response.collection.models.map((model) => {
|
|
|
|
if (requestedColumns) {
|
|
|
|
model.attributes = _.pick(model.attributes, requestedColumns);
|
|
|
|
model._previousAttributes = _.pick(model._previousAttributes, requestedColumns);
|
|
|
|
}
|
2016-03-29 20:36:04 +03:00
|
|
|
|
2018-09-26 15:11:22 +03:00
|
|
|
return model;
|
2016-07-18 23:21:47 +03:00
|
|
|
});
|
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
|
|
|
|
2018-09-26 15:11:22 +03:00
|
|
|
return {
|
|
|
|
data: data,
|
|
|
|
meta: {pagination: response.pagination}
|
|
|
|
};
|
2020-02-14 12:33:10 +03:00
|
|
|
}).catch((err) => {
|
|
|
|
throw err;
|
2015-11-03 14:38:29 +03:00
|
|
|
});
|
2015-06-17 16:55:39 +03:00
|
|
|
},
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
/**
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* ### Find One
|
|
|
|
* Naive find one where data determines what to match on
|
|
|
|
* @param {Object} data
|
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
|
|
|
* @param {Object} unfilteredOptions (optional)
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<ghostBookshelf.Model>} Single Model
|
2013-06-25 15:43:15 +04:00
|
|
|
*/
|
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
|
|
|
findOne: function findOne(data, unfilteredOptions) {
|
2019-02-22 14:07:34 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'findOne');
|
2014-05-06 05:45:08 +04:00
|
|
|
data = this.filterData(data);
|
2019-02-22 14:07:34 +03:00
|
|
|
const model = this.forge(data);
|
|
|
|
|
|
|
|
// @NOTE: The API layer decides if this option is allowed
|
|
|
|
if (options.filter) {
|
|
|
|
model.applyDefaultAndCustomFilters(options);
|
|
|
|
}
|
|
|
|
|
2019-03-05 12:19:24 +03:00
|
|
|
// Ensure only valid fields/columns are added to query
|
|
|
|
if (options.columns) {
|
|
|
|
options.columns = _.intersection(options.columns, this.prototype.permittedAttributes());
|
|
|
|
}
|
|
|
|
|
2019-02-22 14:07:34 +03:00
|
|
|
return model.fetch(options);
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* ### Edit
|
2013-06-25 15:43:15 +04:00
|
|
|
* Naive edit
|
2017-04-19 16:53:23 +03:00
|
|
|
*
|
|
|
|
* We always forward the `method` option to Bookshelf, see http://bookshelfjs.org/#Model-instance-save.
|
|
|
|
* Based on the `method` option Bookshelf and Ghost can determine if a query is an insert or an update.
|
|
|
|
*
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* @param {Object} data
|
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
|
|
|
* @param {Object} unfilteredOptions (optional)
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<ghostBookshelf.Model>} Edited Model
|
2013-06-25 15:43:15 +04:00
|
|
|
*/
|
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
|
|
|
edit: function edit(data, unfilteredOptions) {
|
2018-09-20 15:58:57 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'edit');
|
|
|
|
const id = options.id;
|
2019-02-22 14:07:34 +03:00
|
|
|
const model = this.forge({id: id});
|
2016-06-03 11:06:18 +03:00
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
data = this.filterData(data);
|
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
|
|
|
|
2019-02-22 14:07:34 +03:00
|
|
|
// @NOTE: The API layer decides if this option is allowed
|
|
|
|
if (options.filter) {
|
|
|
|
model.applyDefaultAndCustomFilters(options);
|
|
|
|
}
|
|
|
|
|
2016-06-03 11:06:18 +03:00
|
|
|
// We allow you to disable timestamps when run migration, so that the posts `updated_at` value is the same
|
|
|
|
if (options.importing) {
|
|
|
|
model.hasTimestamps = false;
|
|
|
|
}
|
|
|
|
|
2019-02-22 06:17:14 +03:00
|
|
|
return model
|
|
|
|
.fetch(options)
|
|
|
|
.then((object) => {
|
|
|
|
if (object) {
|
|
|
|
options.method = 'update';
|
|
|
|
return object.save(data, options);
|
|
|
|
}
|
|
|
|
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.NotFoundError();
|
2019-02-22 06:17:14 +03:00
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* ### Add
|
|
|
|
* Naive add
|
|
|
|
* @param {Object} data
|
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
|
|
|
* @param {Object} unfilteredOptions (optional)
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<ghostBookshelf.Model>} Newly Added Model
|
2013-06-25 15:43:15 +04:00
|
|
|
*/
|
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
|
|
|
add: function add(data, unfilteredOptions) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'add');
|
|
|
|
let model;
|
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
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
data = this.filterData(data);
|
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
|
|
|
model = this.forge(data);
|
2016-06-03 11:06:18 +03: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
|
|
|
// We allow you to disable timestamps when importing posts so that the new posts `updated_at` value is the same
|
|
|
|
// as the import json blob. More details refer to https://github.com/TryGhost/Ghost/issues/1696
|
2013-12-26 07:48:16 +04:00
|
|
|
if (options.importing) {
|
2014-09-19 20:17:58 +04:00
|
|
|
model.hasTimestamps = false;
|
2013-12-26 07:48:16 +04:00
|
|
|
}
|
✨ replace auto increment id's by object id (#7495)
* 🛠 bookshelf tarball, bson-objectid
* 🎨 schema changes
- change increment type to string
- add a default fallback for string length 191 (to avoid adding this logic to every single column which uses an ID)
- remove uuid, because ID now represents a global resource identifier
- keep uuid for post, because we are using this as preview id
- keep uuid for clients for now - we are using this param for Ghost-Auth
* ✨ base model: generate ObjectId on creating event
- each new resource get's a auto generate ObjectId
- this logic won't work for attached models, this commit comes later
* 🎨 centralised attach method
When attaching models there are two things important two know
1. To be able to attach an ObjectId, we need to register the `onCreating` event the fetched model!This is caused by the Bookshelf design in general. On this target model we are attaching the new model.
2. We need to manually fetch the target model, because Bookshelf has a weird behaviour (which is known as a bug, see see https://github.com/tgriesser/bookshelf/issues/629). The most important property when attaching a model is `parentFk`, which is the foreign key. This can be null when fetching the model with the option `withRelated`. To ensure quality and consistency, the custom attach wrapper always fetches the target model manual. By fetching the target model (again) is a little performance decrease, but it also has advantages: we can register the event, and directly unregister the event again. So very clean code.
Important: please only use the custom attach wrapper in the future.
* 🎨 token model had overriden the onCreating function because of the created_at field
- we need to ensure that the base onCreating hook get's triggered for ALL models
- if not, they don't get an ObjectId assigned
- in this case: be smart and check if the target model has a created_at field
* 🎨 we don't have a uuid field anymore, remove the usages
- no default uuid creation in models
- i am pretty sure we have some more definitions in our tests (for example in the export json files), but that is too much work to delete them all
* 🎨 do not parse ID to Number
- we had various occurances of parsing all ID's to numbers
- we don't need this behaviour anymore
- ID is string
- i will adapt the ID validation in the next commit
* 🎨 change ID regex for validation
- we only allow: ID as ObjectId, ID as 1 and ID as me
- we need to keep ID 1, because our whole software relies on ID 1 (permissions etc)
* 🎨 owner fixture
- roles: [4] does not work anymore
- 4 means -> static id 4
- this worked in an auto increment system (not even in a system with distributed writes)
- with ObjectId we generate each ID automatically (for static and dynamic resources)
- it is possible to define all id's for static resources still, but that means we need to know which ID is already used and for consistency we have to define ObjectId's for these static resources
- so no static id's anymore, except of: id 1 for owner and id 0 for external usage (because this is required from our permission system)
- NOTE: please read through the comment in the user model
* 🎨 tests: DataGenerator and test utils
First of all: we need to ensure using ObjectId's in the tests. When don't, we can't ensure that ObjectId's work properly.
This commit brings lot's of dynamic into all the static defined id's.
In one of the next commits, i will adapt all the tests.
* 🚨 remove counter in Notification API
- no need to add a counter
- we simply generate ObjectId's (they are auto incremental as well)
- our id validator does only allow ObjectId as id,1 and me
* 🎨 extend contextUser in Base Model
- remove isNumber check, because id's are no longer numbers, except of id 0/1
- use existing isExternalUser
- support id 0/1 as string or number
* ✨ Ghost Owner has id 1
- ensure we define this id in the fixtures.json
- doesn't matter if number or string
* 🎨 functional tests adaptions
- use dynamic id's
* 🎨 fix unit tests
* 🎨 integration tests adaptions
* 🎨 change importer utils
- all our export examples (test/fixtures/exports) contain id's as numbers
- fact: but we ignore them anyway when inserting into the database, see https://github.com/TryGhost/Ghost/blob/master/core/server/data/import/utils.js#L249
- in https://github.com/TryGhost/Ghost/pull/7495/commits/0e6ed957cd54dc02a25cf6fb1ab7d7e723295e2c#diff-70f514a06347c048648be464819503c4L67 i removed parsing id's to integers
- i realised that this ^ check just existed, because the userIdToMap was an object key and object keys are always strings!
- i think this logic is a little bit complicated, but i don't want to refactor this now
- this commit ensures when trying to find the user, the id comparison works again
- i've added more documentation to understand this logic ;)
- plus i renamed an attribute to improve readability
* 🎨 Data-Generator: add more defaults to createUser
- if i use the function DataGenerator.forKnex.createUser i would like to get a full set of defaults
* 🎨 test utils: change/extend function set for functional tests
- functional tests work a bit different
- they boot Ghost and seed the database
- some functional tests have mis-used the test setup
- the test setup needs two sections: integration/unit and functional tests
- any functional test is allowed to either add more data or change data in the existing Ghost db
- but what it should not do is: add test fixtures like roles or users from our DataGenerator and cross fingers it will work
- this commit adds a clean method for functional tests to add extra users
* 🎨 functional tests adaptions
- use last commit to insert users for functional tests clean
- tidy up usage of testUtils.setup or testUtils.doAuth
* 🐛 test utils: reset database before init
- ensure we don't have any left data from other tests in the database when starting ghost
* 🐛 fix test (unrelated to this PR)
- fixes a random failure
- return statement was missing
* 🎨 make changes for invites
2016-11-17 12:09:11 +03:00
|
|
|
|
|
|
|
// Bookshelf determines whether an operation is an update or an insert based on the id
|
|
|
|
// Ghost auto-generates Object id's, so we need to tell Bookshelf here that we are inserting data
|
|
|
|
options.method = 'insert';
|
2014-09-19 20:17:58 +04:00
|
|
|
return model.save(null, options);
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
|
|
|
|
2020-08-20 11:24:05 +03:00
|
|
|
bulkAdd: function bulkAdd(data, tableName) {
|
|
|
|
tableName = tableName || this.prototype.tableName;
|
|
|
|
|
|
|
|
return bulkOperations.insert(tableName, data);
|
|
|
|
},
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
/**
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* ### Destroy
|
2013-06-25 15:43:15 +04:00
|
|
|
* Naive destroy
|
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
|
|
|
* @param {Object} unfilteredOptions (optional)
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<ghostBookshelf.Model>} Empty Model
|
2013-06-25 15:43:15 +04:00
|
|
|
*/
|
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
|
|
|
destroy: function destroy(unfilteredOptions) {
|
2018-09-20 15:58:57 +03:00
|
|
|
const options = this.filterOptions(unfilteredOptions, 'destroy');
|
2019-02-22 06:17:14 +03:00
|
|
|
|
2018-10-01 15:44:52 +03:00
|
|
|
if (!options.destroyBy) {
|
|
|
|
options.destroyBy = {
|
|
|
|
id: options.id
|
|
|
|
};
|
|
|
|
}
|
2015-03-24 23:23:23 +03:00
|
|
|
|
|
|
|
// Fetch the object before destroying it, so that the changed data is available to events
|
2018-10-01 15:44:52 +03:00
|
|
|
return this.forge(options.destroyBy)
|
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
|
|
|
.fetch(options)
|
|
|
|
.then(function then(obj) {
|
|
|
|
return obj.destroy(options);
|
|
|
|
});
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
|
|
|
|
2020-08-20 11:24:05 +03:00
|
|
|
bulkDestroy: function bulkDestroy(data, tableName) {
|
|
|
|
tableName = tableName || this.prototype.tableName;
|
|
|
|
|
|
|
|
return bulkOperations.del(tableName, data);
|
|
|
|
},
|
|
|
|
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
/**
|
2017-04-19 16:53:23 +03:00
|
|
|
* ### Generate Slug
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
* Create a string to act as the permalink for an object.
|
|
|
|
* @param {ghostBookshelf.Model} Model Model type to generate a slug for
|
|
|
|
* @param {String} base The string for which to generate a slug, usually a title or name
|
|
|
|
* @param {Object} options Options to pass to findOne
|
2021-06-15 15:28:59 +03:00
|
|
|
* @return {Promise<String>} Resolves to a unique slug string
|
2017-04-19 16:53:23 +03:00
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
generateSlug: function generateSlug(Model, base, options) {
|
2020-04-29 18:44:27 +03:00
|
|
|
let slug;
|
|
|
|
let slugTryCount = 1;
|
|
|
|
const baseName = Model.prototype.tableName.replace(/s$/, '');
|
|
|
|
|
|
|
|
let longSlug;
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
// Look for a matching slug, append an incrementing number if so
|
|
|
|
const checkIfSlugExists = function checkIfSlugExists(slugToFind) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const args = {slug: slugToFind};
|
2016-10-14 20:24:38 +03:00
|
|
|
|
2014-09-10 08:06:24 +04:00
|
|
|
// status is needed for posts
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
if (options && options.status) {
|
|
|
|
args.status = options.status;
|
2014-03-23 22:52:25 +04:00
|
|
|
}
|
2016-10-14 20:24:38 +03:00
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
return Model.findOne(args, options).then(function then(found) {
|
2020-04-29 18:44:27 +03:00
|
|
|
let trimSpace;
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2014-03-23 22:52:25 +04:00
|
|
|
if (!found) {
|
2014-08-17 10:17:23 +04:00
|
|
|
return slugToFind;
|
2014-03-23 22:52:25 +04:00
|
|
|
}
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2014-03-23 22:52:25 +04:00
|
|
|
slugTryCount += 1;
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2014-09-30 02:45:58 +04:00
|
|
|
// If we shortened, go back to the full version and try again
|
|
|
|
if (slugTryCount === 2 && longSlug) {
|
|
|
|
slugToFind = longSlug;
|
|
|
|
longSlug = null;
|
|
|
|
slugTryCount = 1;
|
|
|
|
return checkIfSlugExists(slugToFind);
|
|
|
|
}
|
|
|
|
|
2014-03-23 22:52:25 +04:00
|
|
|
// If this is the first time through, add the hyphen
|
|
|
|
if (slugTryCount === 2) {
|
|
|
|
slugToFind += '-';
|
|
|
|
} else {
|
|
|
|
// Otherwise, trim the number off the end
|
|
|
|
trimSpace = -(String(slugTryCount - 1).length);
|
|
|
|
slugToFind = slugToFind.slice(0, trimSpace);
|
|
|
|
}
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2014-03-23 22:52:25 +04:00
|
|
|
slugToFind += slugTryCount;
|
|
|
|
|
|
|
|
return checkIfSlugExists(slugToFind);
|
|
|
|
});
|
|
|
|
};
|
2013-12-20 17:36:00 +04:00
|
|
|
|
2019-05-07 07:48:28 +03:00
|
|
|
slug = security.string.safe(base, options);
|
2018-12-13 15:06:59 +03:00
|
|
|
|
2017-11-21 16:21:22 +03:00
|
|
|
// the slug may never be longer than the allowed limit of 191 chars, but should also
|
|
|
|
// take the counter into count. We reduce a too long slug to 185 so we're always on the
|
|
|
|
// safe side, also in terms of checking for existing slugs already.
|
|
|
|
if (slug.length > 185) {
|
|
|
|
// CASE: don't cut the slug on import
|
|
|
|
if (!_.has(options, 'importing') || !options.importing) {
|
|
|
|
slug = slug.slice(0, 185);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2014-09-30 02:45:58 +04:00
|
|
|
// If it's a user, let's try to cut it down (unless this is a human request)
|
|
|
|
if (baseName === 'user' && options && options.shortSlug && slugTryCount === 1 && slug !== 'ghost-owner') {
|
|
|
|
longSlug = slug;
|
|
|
|
slug = (slug.indexOf('-') > -1) ? slug.substr(0, slug.indexOf('-')) : slug;
|
|
|
|
}
|
|
|
|
|
2016-06-11 18:12:04 +03:00
|
|
|
if (!_.has(options, 'importing') || !options.importing) {
|
|
|
|
// This checks if the first character of a tag name is a #. If it is, this
|
|
|
|
// is an internal tag, and as such we should add 'hash' to the beginning of the slug
|
2016-10-10 11:51:03 +03:00
|
|
|
if (baseName === 'tag' && /^#/.test(base)) {
|
2016-06-11 18:12:04 +03:00
|
|
|
slug = 'hash-' + slug;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-04-15 17:15:32 +03:00
|
|
|
// Some keywords cannot be changed
|
2019-11-18 17:25:33 +03:00
|
|
|
slug = _.includes(urlUtils.getProtectedSlugs(), slug) ? slug + '-' + baseName : slug;
|
2014-09-07 00:16:14 +04:00
|
|
|
|
2019-04-15 17:15:32 +03:00
|
|
|
// if slug is empty after trimming use the model name
|
|
|
|
if (!slug) {
|
|
|
|
slug = baseName;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Test for duplicate slugs.
|
|
|
|
return checkIfSlugExists(slug);
|
2015-10-22 15:49:15 +03:00
|
|
|
},
|
|
|
|
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
/**
|
|
|
|
* If you want to fetch all data fast, i recommend using this function.
|
|
|
|
* Bookshelf is just too slow, too much ORM overhead.
|
|
|
|
*
|
|
|
|
* If we e.g. instantiate for each object a model, it takes twice long.
|
|
|
|
*/
|
|
|
|
raw_knex: {
|
|
|
|
fetchAll: function (options) {
|
|
|
|
options = options || {};
|
|
|
|
|
🐛 Fixed all known filter limitations (#10159)
refs #10105, closes #10108, closes https://github.com/TryGhost/Ghost/issues/9950, refs https://github.com/TryGhost/Ghost/issues/9923, refs https://github.com/TryGhost/Ghost/issues/9916, refs https://github.com/TryGhost/Ghost/issues/9574, refs https://github.com/TryGhost/Ghost/issues/6345, refs https://github.com/TryGhost/Ghost/issues/6309, refs https://github.com/TryGhost/Ghost/issues/6158, refs https://github.com/TryGhost/GQL/issues/16
- removed GQL dependency
- replaced GQL with our brand new NQL implementation
- fixed all known filter limitations
- GQL suffered from some underlying filter bugs, which NQL tried to fix
- the bugs were mostly in how we query the database for relation filtering
- the underlying problem was caused by a too simple implementation of querying the relations
- mongo-knex has implemented a more robust and complex filtering mechanism for relations
- replaced logic in our bookshelf filter plugin
- we pass the custom, default and override filters from Ghost to NQL, which then are getting parsed and merged into a mongo JSON object. The mongo JSON is getting attached by mongo-knex.
NQL: https://github.com/NexesJS/NQL
mongo-knex: https://github.com/NexesJS/mongo-knex
2018-12-11 13:53:40 +03:00
|
|
|
const nql = require('@nexes/nql');
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
const modelName = options.modelName;
|
|
|
|
const tableNames = {
|
|
|
|
Post: 'posts',
|
|
|
|
User: 'users',
|
|
|
|
Tag: 'tags'
|
|
|
|
};
|
2018-08-12 13:22:23 +03:00
|
|
|
const exclude = options.exclude;
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
const filter = options.filter;
|
2019-01-03 22:30:35 +03:00
|
|
|
const shouldHavePosts = options.shouldHavePosts;
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
const withRelated = options.withRelated;
|
|
|
|
const withRelatedFields = options.withRelatedFields;
|
|
|
|
const relations = {
|
|
|
|
tags: {
|
|
|
|
targetTable: 'tags',
|
|
|
|
name: 'tags',
|
|
|
|
innerJoin: {
|
|
|
|
relation: 'posts_tags',
|
|
|
|
condition: ['posts_tags.tag_id', '=', 'tags.id']
|
|
|
|
},
|
✨Dynamic Routing Beta (#9596)
refs #9601
### Dynamic Routing
This is the beta version of dynamic routing.
- we had a initial implementation of "channels" available in the codebase
- we have removed and moved this implementation
- there is now a centralised place for dynamic routing - server/services/routing
- each routing component is represented by a router type e.g. collections, routes, static pages, taxonomies, rss, preview of posts
- keep as much as possible logic of routing helpers, middlewares and controllers
- ensure test coverage
- connect all the things together
- yaml file + validation
- routing + routers
- url service
- sitemaps
- url access
- deeper implementation of yaml validations
- e.g. hard require slashes
- ensure routing hierarchy/order
- e.g. you enable the subscriber app
- you have a custom static page, which lives under the same slug /subscribe
- static pages are stronger than apps
- e.g. the first collection owns the post it has filtered
- a post cannot live in two collections
- ensure apps are still working and hook into the routers layer (or better said: and register in the routing service)
- put as much as possible comments to the code base for better understanding
- ensure a clean debug log
- ensure we can unmount routes
- e.g. you have a collection permalink of /:slug/ represented by {globals.permalink}
- and you change the permalink in the admin to dated permalink
- the express route get's refreshed from /:slug/ to /:year/:month/:day/:slug/
- unmount without server restart, yey
- ensure we are backwards compatible
- e.g. render home.hbs for collection index if collection route is /
- ensure you can access your configured permalink from the settings table with {globals.permalink}
### Render 503 if url service did not finish
- return 503 if the url service has not finished generating the resource urls
### Rewrite sitemaps
- we have rewritten the sitemaps "service", because the url generator does no longer happen on runtime
- we generate all urls on bootstrap
- the sitemaps service will consume created resource and router urls
- these urls will be shown on the xml pages
- we listen on url events
- we listen on router events
- we no longer have to fetch the resources, which is nice
- the urlservice pre-fetches resources and emits their urls
- the urlservice is the only component who knows which urls are valid
- i made some ES6 adaptions
- we keep the caching logic -> only regenerate xml if there is a change
- updated tests
- checked test coverage (100%)
### Re-work usage of Url utility
- replace all usages of `urlService.utils.urlFor` by `urlService.getByResourceId`
- only for resources e.g. post, author, tag
- this is important, because with dynamic routing we no longer create static urls based on the settings permalink on runtime
- adapt url utility
- adapt tests
2018-06-05 20:02:20 +03:00
|
|
|
select: ['posts_tags.post_id as post_id', 'tags.visibility'],
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
whereIn: 'posts_tags.post_id',
|
|
|
|
whereInKey: 'post_id',
|
|
|
|
orderBy: 'sort_order'
|
|
|
|
},
|
|
|
|
authors: {
|
|
|
|
targetTable: 'users',
|
|
|
|
name: 'authors',
|
|
|
|
innerJoin: {
|
|
|
|
relation: 'posts_authors',
|
|
|
|
condition: ['posts_authors.author_id', '=', 'users.id']
|
|
|
|
},
|
|
|
|
select: ['posts_authors.post_id as post_id'],
|
|
|
|
whereIn: 'posts_authors.post_id',
|
|
|
|
whereInKey: 'post_id',
|
|
|
|
orderBy: 'sort_order'
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
let query = ghostBookshelf.knex(tableNames[modelName]);
|
|
|
|
|
2018-08-08 20:17:01 +03:00
|
|
|
if (options.offset) {
|
|
|
|
query.offset(options.offset);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (options.limit) {
|
|
|
|
query.limit(options.limit);
|
|
|
|
}
|
|
|
|
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
// exclude fields if enabled
|
2018-08-12 13:22:23 +03:00
|
|
|
if (exclude) {
|
Added unique constraint notation to schema definition
refs https://github.com/TryGhost/Ghost/issues/12567
- Introduced here @@UNIQUE_CONSTRAINTS@@ notation allows to create unique contraints over multiple database fields. This will be needed to change posts' table unique constraint from `slug` to `slug+type`.
- The notation is equivalent to SQL's: UNIQUE(column_name1,column_name2)
- Example use in schema:
posts: {
slug: {type: 'string', maxlength: 191, nullable: false},
type: {type: 'string', maxlength: 50, nullable: false, defaultTo: 'post', validations: {isIn: [['post', 'page']]}},
'@@UNIQUES@@': [
['slug', 'type']
]
}
2021-02-04 03:17:50 +03:00
|
|
|
let toSelect = _.keys(schema.tables[tableNames[modelName]]);
|
|
|
|
toSelect = toSelect.filter(key => !(key.startsWith('@@')));
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
|
2018-08-12 13:22:23 +03:00
|
|
|
_.each(exclude, (key) => {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
if (toSelect.indexOf(key) !== -1) {
|
|
|
|
toSelect.splice(toSelect.indexOf(key), 1);
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
query.select(toSelect);
|
|
|
|
}
|
|
|
|
|
🐛 Fixed all known filter limitations (#10159)
refs #10105, closes #10108, closes https://github.com/TryGhost/Ghost/issues/9950, refs https://github.com/TryGhost/Ghost/issues/9923, refs https://github.com/TryGhost/Ghost/issues/9916, refs https://github.com/TryGhost/Ghost/issues/9574, refs https://github.com/TryGhost/Ghost/issues/6345, refs https://github.com/TryGhost/Ghost/issues/6309, refs https://github.com/TryGhost/Ghost/issues/6158, refs https://github.com/TryGhost/GQL/issues/16
- removed GQL dependency
- replaced GQL with our brand new NQL implementation
- fixed all known filter limitations
- GQL suffered from some underlying filter bugs, which NQL tried to fix
- the bugs were mostly in how we query the database for relation filtering
- the underlying problem was caused by a too simple implementation of querying the relations
- mongo-knex has implemented a more robust and complex filtering mechanism for relations
- replaced logic in our bookshelf filter plugin
- we pass the custom, default and override filters from Ghost to NQL, which then are getting parsed and merged into a mongo JSON object. The mongo JSON is getting attached by mongo-knex.
NQL: https://github.com/NexesJS/NQL
mongo-knex: https://github.com/NexesJS/mongo-knex
2018-12-11 13:53:40 +03:00
|
|
|
// @NOTE: We can't use the filter plugin, because we are not using bookshelf.
|
|
|
|
nql(filter).querySQL(query);
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
|
2019-01-03 22:30:35 +03:00
|
|
|
if (shouldHavePosts) {
|
2021-06-15 13:57:47 +03:00
|
|
|
plugins.hasPosts.addHasPostsWhere(tableNames[modelName], shouldHavePosts)(query);
|
2019-01-03 22:30:35 +03:00
|
|
|
}
|
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
if (options.id) {
|
|
|
|
query.where({id: options.id});
|
|
|
|
}
|
|
|
|
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
return query.then((objects) => {
|
|
|
|
debug('fetched', modelName, filter);
|
|
|
|
|
2018-08-08 20:17:01 +03:00
|
|
|
if (!objects.length) {
|
|
|
|
debug('No more entries found');
|
|
|
|
return Promise.resolve([]);
|
|
|
|
}
|
|
|
|
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
let props = {};
|
|
|
|
|
|
|
|
if (!withRelated) {
|
|
|
|
return _.map(objects, (object) => {
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.toJSON.bind({
|
|
|
|
attributes: object,
|
|
|
|
related: function (key) {
|
|
|
|
return object[key];
|
|
|
|
},
|
|
|
|
serialize: ghostBookshelf._models[modelName].prototype.serialize,
|
|
|
|
formatsToJSON: ghostBookshelf._models[modelName].prototype.formatsToJSON
|
|
|
|
})();
|
|
|
|
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.fixBools(object);
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.fixDatesWhenFetch(object);
|
|
|
|
return object;
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
_.each(withRelated, (withRelatedKey) => {
|
|
|
|
const relation = relations[withRelatedKey];
|
|
|
|
|
|
|
|
props[relation.name] = (() => {
|
|
|
|
debug('fetch withRelated', relation.name);
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
let relationQuery = db.knex(relation.targetTable);
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
|
|
|
|
// default fields to select
|
|
|
|
_.each(relation.select, (fieldToSelect) => {
|
2020-10-20 02:02:56 +03:00
|
|
|
relationQuery.select(fieldToSelect);
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
});
|
|
|
|
|
|
|
|
// custom fields to select
|
|
|
|
_.each(withRelatedFields[withRelatedKey], (toSelect) => {
|
2020-10-20 02:02:56 +03:00
|
|
|
relationQuery.select(toSelect);
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
});
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
relationQuery.innerJoin(
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
relation.innerJoin.relation,
|
|
|
|
relation.innerJoin.condition[0],
|
|
|
|
relation.innerJoin.condition[1],
|
|
|
|
relation.innerJoin.condition[2]
|
|
|
|
);
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
relationQuery.whereIn(relation.whereIn, _.map(objects, 'id'));
|
|
|
|
relationQuery.orderBy(relation.orderBy);
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
return relationQuery
|
|
|
|
.then((queryRelations) => {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
debug('fetched withRelated', relation.name);
|
|
|
|
|
|
|
|
// arr => obj[post_id] = [...] (faster access)
|
2020-10-20 02:02:56 +03:00
|
|
|
return queryRelations.reduce((obj, item) => {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
if (!obj[item[relation.whereInKey]]) {
|
|
|
|
obj[item[relation.whereInKey]] = [];
|
|
|
|
}
|
|
|
|
|
|
|
|
obj[item[relation.whereInKey]].push(_.omit(item, relation.select));
|
|
|
|
return obj;
|
|
|
|
}, {});
|
|
|
|
});
|
|
|
|
})();
|
|
|
|
});
|
|
|
|
|
|
|
|
return Promise.props(props)
|
2020-10-20 02:02:56 +03:00
|
|
|
.then((relationsToAttach) => {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
debug('attach relations', modelName);
|
|
|
|
|
|
|
|
objects = _.map(objects, (object) => {
|
2020-10-20 02:02:56 +03:00
|
|
|
_.each(Object.keys(relationsToAttach), (relation) => {
|
|
|
|
if (!relationsToAttach[relation][object.id]) {
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
object[relation] = [];
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-10-20 02:02:56 +03:00
|
|
|
object[relation] = relationsToAttach[relation][object.id];
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
});
|
|
|
|
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.toJSON.bind({
|
|
|
|
attributes: object,
|
|
|
|
_originalOptions: {
|
2020-10-20 02:02:56 +03:00
|
|
|
withRelated: Object.keys(relationsToAttach)
|
Rewrite url service (#9550)
refs https://github.com/TryGhost/Team/issues/65
We are currently work on dynamic routing (aka channels).
An important piece of this feature is the url service, which always knows the url of a resource at any time.
Resources can belong to collections or taxonomies, which can be defined in a [routing yaml file](https://github.com/TryGhost/Ghost/issues/9528). We are currently shipping portions, which will at end form the full dynamic routing feature.
### Key Notes
- each routing type (collections, taxonomies, static pages) is registered in order - depending on the yaml routes file configuration
- static pages are an internal concept - they sit at the end of the subscriber queue
- we make use of a temporary [`Channels2`](https://github.com/TryGhost/Ghost/pull/9550/files#diff-9e7251409844521470c9829013cd1563) file, which simulates the current static routing in Ghost (this file will be modified, removed or whatever - this is one of the next steps)
- two way binding: you can ask for a resource url based on the resource id, you can ask for the resource based on the url
- in theory it's possible that multiple resources generate the same url: we don't handle this with collision (because this is error prone), we handle this with the order of serving content. if you ask the service for a resource, which lives behind e.g. /test/, you will get the resource which is served
- loose error handling -> log errors and handle instead of throw error and do nothing (we log the errors with a specific code, so we can react in case there is a bug)
- the url services fetches all resources on bootstrap. we only fetch and keep a reduced set of attributes (basically the main body of a resource)
- the bootstrap time will decrease a very little (depending on the amount of resources you have in your database)
- we still offer the option to disable url preloading (in your config `disableUrlPreload: true`) - this option will be removed as soon as the url service is connected. You can disable the service in case you encounter a problem
- **the url service is not yet connected, we will connect the service step by step. The first version should be released to pre-catch bugs. The next version will add 503 handling if the url service is not ready and it will consume urls for resources.**
----
- the url service generates urls based on resources (posts, pages, users, tags)
- the url service keeps track of resource changes
- the url service keeps track of resource removal/insert
- the architecture:
- each routing type is represented by a url generator
- a routing type is a collection, a taxonomiy or static pages
- a queue which ensures that urls are unique and can be owned by one url generator
- the hierarchy of registration defines that
- we query knex, because bookshelf is too slow
- removed old url service files + logic
- added temp channels alternative (Channels2) -> this file will look different soon, it's for now the temporary connector to the url service. Also the name of the file is not optimal, but that is not really important right now.
2018-04-17 12:29:04 +03:00
|
|
|
},
|
|
|
|
related: function (key) {
|
|
|
|
return object[key];
|
|
|
|
},
|
|
|
|
serialize: ghostBookshelf._models[modelName].prototype.serialize,
|
|
|
|
formatsToJSON: ghostBookshelf._models[modelName].prototype.formatsToJSON
|
|
|
|
})();
|
|
|
|
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.fixBools(object);
|
|
|
|
object = ghostBookshelf._models[modelName].prototype.fixDatesWhenFetch(object);
|
|
|
|
return object;
|
|
|
|
});
|
|
|
|
|
|
|
|
debug('attached relations', modelName);
|
|
|
|
|
|
|
|
return objects;
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
2017-12-13 15:19:51 +03:00
|
|
|
}
|
2013-06-25 15:43:15 +04:00
|
|
|
});
|
|
|
|
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
// Export ghostBookshelf for use elsewhere
|
2013-09-23 02:20:08 +04:00
|
|
|
module.exports = ghostBookshelf;
|