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
|
|
|
// # Post Model
|
2018-10-09 16:31:09 +03:00
|
|
|
const _ = require('lodash');
|
|
|
|
const uuid = require('uuid');
|
|
|
|
const moment = require('moment');
|
|
|
|
const Promise = require('bluebird');
|
2020-08-11 20:44:21 +03:00
|
|
|
const {sequence} = require('@tryghost/promise');
|
2020-05-22 21:22:20 +03:00
|
|
|
const {i18n} = require('../lib/common');
|
|
|
|
const errors = require('@tryghost/errors');
|
2018-10-09 16:31:09 +03:00
|
|
|
const htmlToText = require('html-to-text');
|
|
|
|
const ghostBookshelf = require('./base');
|
2020-05-27 20:47:53 +03:00
|
|
|
const config = require('../../shared/config');
|
2019-09-26 16:40:24 +03:00
|
|
|
const settingsCache = require('../services/settings/cache');
|
2020-04-08 18:42:55 +03:00
|
|
|
const mobiledocLib = require('../lib/mobiledoc');
|
2018-10-09 16:31:09 +03:00
|
|
|
const relations = require('./relations');
|
2020-05-28 13:57:02 +03:00
|
|
|
const urlUtils = require('../../shared/url-utils');
|
2018-10-09 16:31:09 +03:00
|
|
|
const MOBILEDOC_REVISIONS_COUNT = 10;
|
2018-11-15 17:53:24 +03:00
|
|
|
const ALL_STATUSES = ['published', 'draft', 'scheduled'];
|
2018-10-09 16:31:09 +03:00
|
|
|
|
|
|
|
let Post;
|
|
|
|
let Posts;
|
2013-06-25 15:43:15 +04:00
|
|
|
|
2013-09-23 02:20:08 +04:00
|
|
|
Post = ghostBookshelf.Model.extend({
|
2013-06-25 15:43:15 +04:00
|
|
|
|
|
|
|
tableName: 'posts',
|
|
|
|
|
2018-02-16 02:49:15 +03:00
|
|
|
/**
|
2018-06-26 17:00:54 +03:00
|
|
|
* @NOTE
|
|
|
|
*
|
2018-02-16 02:49:15 +03:00
|
|
|
* We define the defaults on the schema (db) and model level.
|
|
|
|
*
|
2018-06-26 17:00:54 +03:00
|
|
|
* Why?
|
|
|
|
* - when you insert a resource, Knex does only return the id of the created resource
|
|
|
|
* - see https://knexjs.org/#Builder-insert
|
|
|
|
* - that means `defaultTo` is a pure database configuration (!)
|
|
|
|
* - Bookshelf just returns the model values which you have asked Bookshelf to insert
|
|
|
|
* - it can't return the `defaultTo` value from the schema/db level
|
|
|
|
* - but the db defaults defined in the schema are saved in the database correctly
|
|
|
|
* - `models.Post.add` always does to operations:
|
|
|
|
* 1. add
|
|
|
|
* 2. fetch (this ensures we fetch the whole resource from the database)
|
|
|
|
* - that means we have to apply the defaults on the model layer to ensure a complete field set
|
|
|
|
* 1. any connected logic in our model hooks e.g. beforeSave
|
|
|
|
* 2. model events e.g. "post.published" are using the inserted resource, not the fetched resource
|
2018-02-16 02:49:15 +03:00
|
|
|
*/
|
|
|
|
defaults: function defaults() {
|
2019-09-26 16:40:24 +03:00
|
|
|
let visibility = 'public';
|
|
|
|
|
2019-10-02 12:08:10 +03:00
|
|
|
if (settingsCache.get('labs') && (settingsCache.get('labs').members === true) && settingsCache.get('default_content_visibility')) {
|
|
|
|
visibility = settingsCache.get('default_content_visibility');
|
2019-09-26 16:40:24 +03:00
|
|
|
}
|
|
|
|
|
2018-02-16 02:49:15 +03:00
|
|
|
return {
|
|
|
|
uuid: uuid.v4(),
|
2018-06-26 17:00:54 +03:00
|
|
|
status: 'draft',
|
|
|
|
featured: false,
|
2019-09-16 13:51:54 +03:00
|
|
|
type: 'post',
|
2020-11-03 16:58:23 +03:00
|
|
|
visibility: visibility,
|
|
|
|
email_recipient_filter: 'none'
|
2018-02-16 02:49:15 +03:00
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2019-09-16 11:45:55 +03:00
|
|
|
relationships: ['tags', 'authors', 'mobiledoc_revisions', 'posts_meta'],
|
2017-11-21 16:28:05 +03:00
|
|
|
|
2018-04-05 17:11:47 +03:00
|
|
|
// NOTE: look up object, not super nice, but was easy to implement
|
|
|
|
relationshipBelongsTo: {
|
|
|
|
tags: 'tags',
|
2019-09-16 11:45:55 +03:00
|
|
|
authors: 'users',
|
|
|
|
posts_meta: 'posts_meta'
|
2018-04-05 17:11:47 +03:00
|
|
|
},
|
|
|
|
|
2020-09-24 04:32:40 +03:00
|
|
|
relationsMeta: {
|
|
|
|
posts_meta: {
|
|
|
|
targetTableName: 'posts_meta',
|
|
|
|
foreignKey: 'post_id'
|
|
|
|
}
|
|
|
|
},
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
/**
|
|
|
|
* The base model keeps only the columns, which are defined in the schema.
|
|
|
|
* We have to add the relations on top, otherwise bookshelf-relations
|
|
|
|
* has no access to the nested relations, which should be updated.
|
|
|
|
*/
|
|
|
|
permittedAttributes: function permittedAttributes() {
|
|
|
|
let filteredKeys = ghostBookshelf.Model.prototype.permittedAttributes.apply(this, arguments);
|
|
|
|
|
|
|
|
this.relationships.forEach((key) => {
|
|
|
|
filteredKeys.push(key);
|
|
|
|
});
|
|
|
|
|
|
|
|
return filteredKeys;
|
|
|
|
},
|
|
|
|
|
2020-09-24 04:32:40 +03:00
|
|
|
orderAttributes: function orderAttributes() {
|
|
|
|
let keys = ghostBookshelf.Model.prototype.orderAttributes.apply(this, arguments);
|
|
|
|
|
|
|
|
// extend ordered keys with post_meta keys
|
|
|
|
let postsMetaKeys = _.without(ghostBookshelf.model('PostsMeta').prototype.orderAttributes(), 'posts_meta.id', 'posts_meta.post_id');
|
|
|
|
|
|
|
|
return [...keys, ...postsMetaKeys];
|
|
|
|
},
|
|
|
|
|
2020-11-02 02:53:57 +03:00
|
|
|
filterExpansions: function filterExpansions() {
|
|
|
|
const postsMetaKeys = _.without(ghostBookshelf.model('PostsMeta').prototype.orderAttributes(), 'posts_meta.id', 'posts_meta.post_id');
|
|
|
|
|
|
|
|
return postsMetaKeys.map((pmk) => {
|
|
|
|
return {
|
|
|
|
key: pmk.split('.')[1],
|
|
|
|
replacement: pmk
|
|
|
|
};
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
2019-01-21 23:53:11 +03:00
|
|
|
emitChange: function emitChange(event, options = {}) {
|
2018-04-06 19:19:45 +03:00
|
|
|
let eventToTrigger;
|
2019-09-16 13:51:54 +03:00
|
|
|
let resourceType = this.get('type');
|
2017-05-22 11:24:59 +03:00
|
|
|
|
2019-01-21 23:53:11 +03:00
|
|
|
if (options.usePreviousAttribute) {
|
2019-09-16 13:51:54 +03:00
|
|
|
resourceType = this.previous('type');
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
2017-01-25 16:47:49 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
eventToTrigger = resourceType + '.' + event;
|
|
|
|
|
|
|
|
ghostBookshelf.Model.prototype.emitChange.bind(this)(this, eventToTrigger, options);
|
2015-03-24 23:23:23 +03:00
|
|
|
},
|
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
/**
|
|
|
|
* We update the tags after the Post was inserted.
|
|
|
|
* We update the tags before the Post was updated, see `onSaving` event.
|
|
|
|
* `onCreated` is called before `onSaved`.
|
2018-03-19 18:27:06 +03:00
|
|
|
*
|
|
|
|
* `onSaved` is the last event in the line - triggered for updating or inserting data.
|
|
|
|
* bookshelf-relations listens on `created` + `updated`.
|
|
|
|
* We ensure that we are catching the event after bookshelf relations.
|
2017-04-19 16:53:23 +03:00
|
|
|
*/
|
2018-03-19 18:27:06 +03:00
|
|
|
onSaved: function onSaved(model, response, options) {
|
2019-02-07 12:59:37 +03:00
|
|
|
ghostBookshelf.Model.prototype.onSaved.apply(this, arguments);
|
|
|
|
|
2018-03-19 18:27:06 +03:00
|
|
|
if (options.method !== 'insert') {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2020-04-29 18:44:27 +03:00
|
|
|
const status = model.get('status');
|
2017-04-19 16:53:23 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('added', options);
|
2014-04-27 20:58:34 +04:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (['published', 'scheduled'].indexOf(status) !== -1) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange(status, options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2017-04-19 16:53:23 +03:00
|
|
|
},
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onUpdated: function onUpdated(model, attrs, options) {
|
2019-02-07 12:59:37 +03:00
|
|
|
ghostBookshelf.Model.prototype.onUpdated.apply(this, arguments);
|
2019-02-07 00:05:03 +03:00
|
|
|
|
2019-01-21 23:53:11 +03:00
|
|
|
model.statusChanging = model.get('status') !== model.previous('status');
|
2016-10-14 15:37:01 +03:00
|
|
|
model.isPublished = model.get('status') === 'published';
|
|
|
|
model.isScheduled = model.get('status') === 'scheduled';
|
2019-01-21 23:53:11 +03:00
|
|
|
model.wasPublished = model.previous('status') === 'published';
|
|
|
|
model.wasScheduled = model.previous('status') === 'scheduled';
|
2019-09-16 13:51:54 +03:00
|
|
|
model.resourceTypeChanging = model.get('type') !== model.previous('type');
|
2016-10-14 15:37:01 +03:00
|
|
|
model.publishedAtHasChanged = model.hasDateChanged('published_at');
|
|
|
|
model.needsReschedule = model.publishedAtHasChanged && model.isScheduled;
|
|
|
|
|
|
|
|
// Handle added and deleted for post -> page or page -> post
|
|
|
|
if (model.resourceTypeChanging) {
|
|
|
|
if (model.wasPublished) {
|
2019-01-21 23:53:11 +03:00
|
|
|
model.emitChange('unpublished', Object.assign({usePreviousAttribute: true}, options));
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2016-04-14 14:22:38 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.wasScheduled) {
|
2019-01-21 23:53:11 +03:00
|
|
|
model.emitChange('unscheduled', Object.assign({usePreviousAttribute: true}, options));
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
|
2019-01-21 23:53:11 +03:00
|
|
|
model.emitChange('deleted', Object.assign({usePreviousAttribute: true}, options));
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('added', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published', options);
|
2014-10-28 03:41:18 +03:00
|
|
|
}
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.isScheduled) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('scheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (model.statusChanging) {
|
|
|
|
// CASE: was published before and is now e.q. draft or scheduled
|
|
|
|
if (model.wasPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', options);
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: was draft or scheduled before and is now e.q. published
|
2015-03-24 23:23:23 +03:00
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
2016-04-14 14:22:38 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: was draft or published before and is now e.q. scheduled
|
2016-04-14 14:22:38 +03:00
|
|
|
if (model.isScheduled) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('scheduled', options);
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// CASE: from scheduled to something
|
|
|
|
if (model.wasScheduled && !model.isScheduled && !model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unscheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if (model.isPublished) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('published.edited', options);
|
2015-03-24 23:23:23 +03:00
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
if (model.needsReschedule) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('rescheduled', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2014-10-28 03:41:18 +03:00
|
|
|
}
|
2015-03-24 23:23:23 +03:00
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
// Fire edited if this wasn't a change between resourceType
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('edited', options);
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
2019-01-08 12:48:53 +03:00
|
|
|
|
|
|
|
if (model.statusChanging && (model.isPublished || model.wasPublished)) {
|
|
|
|
this.handleStatusForAttachedModels(model, options);
|
|
|
|
}
|
2016-10-14 15:37:01 +03:00
|
|
|
},
|
2016-09-19 16:45:36 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onDestroyed: function onDestroyed(model, options) {
|
2019-02-07 12:59:37 +03:00
|
|
|
ghostBookshelf.Model.prototype.onDestroyed.apply(this, arguments);
|
2019-02-07 00:05:03 +03:00
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
if (model.previous('status') === 'published') {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', Object.assign({usePreviousAttribute: true}, options));
|
2017-11-21 16:28:05 +03:00
|
|
|
}
|
2016-10-14 15:37:01 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('deleted', Object.assign({usePreviousAttribute: true}, options));
|
2013-08-20 22:52:44 +04:00
|
|
|
},
|
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
onDestroying: function onDestroyed(model) {
|
2019-02-07 12:59:37 +03:00
|
|
|
ghostBookshelf.Model.prototype.onDestroying.apply(this, arguments);
|
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
this.handleAttachedModels(model);
|
|
|
|
},
|
|
|
|
|
|
|
|
handleAttachedModels: function handleAttachedModels(model) {
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* Bookshelf only exposes the object that is being detached on `detaching`.
|
|
|
|
* For the reason above, `detached` handler is using the scope of `detaching`
|
|
|
|
* to access the models that are not present in `detached`.
|
|
|
|
*/
|
2020-06-12 19:55:40 +03:00
|
|
|
model.related('tags').once('detaching', function detachingTags(collection, tag) {
|
|
|
|
model.related('tags').once('detached', function detachedTags(detachedCollection, response, options) {
|
2019-01-08 12:48:53 +03:00
|
|
|
tag.emitChange('detached', options);
|
2019-02-03 15:36:08 +03:00
|
|
|
model.emitChange('tag.detached', options);
|
2019-01-08 12:48:53 +03:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2020-06-12 19:55:40 +03:00
|
|
|
model.related('tags').once('attaching', function tagsAttaching(collection, tags) {
|
|
|
|
model.related('tags').once('attached', function tagsAttached(detachedCollection, response, options) {
|
2019-02-03 15:36:08 +03:00
|
|
|
tags.forEach((tag) => {
|
|
|
|
tag.emitChange('attached', options);
|
|
|
|
model.emitChange('tag.attached', options);
|
|
|
|
});
|
2019-01-08 12:48:53 +03:00
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2020-06-12 19:55:40 +03:00
|
|
|
model.related('authors').once('detaching', function authorsDetaching(collection, author) {
|
|
|
|
model.related('authors').once('detached', function authorsDetached(detachedCollection, response, options) {
|
2019-01-08 12:48:53 +03:00
|
|
|
author.emitChange('detached', options);
|
|
|
|
});
|
|
|
|
});
|
|
|
|
|
2020-06-12 19:55:40 +03:00
|
|
|
model.related('authors').once('attaching', function authorsAttaching(collection, authors) {
|
|
|
|
model.related('authors').once('attached', function authorsAttached(detachedCollection, response, options) {
|
2019-01-08 12:48:53 +03:00
|
|
|
authors.forEach(author => author.emitChange('attached', options));
|
|
|
|
});
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* when status is changed from or to 'published' all related authors and tags
|
|
|
|
* have to trigger recalculation in URL service because status is applied in filters for
|
|
|
|
* these models
|
|
|
|
*/
|
|
|
|
handleStatusForAttachedModels: function handleStatusForAttachedModels(model, options) {
|
|
|
|
model.related('tags').forEach((tag) => {
|
|
|
|
tag.emitChange('attached', options);
|
|
|
|
});
|
|
|
|
|
|
|
|
model.related('authors').forEach((author) => {
|
|
|
|
author.emitChange('attached', options);
|
|
|
|
});
|
|
|
|
},
|
|
|
|
|
2020-06-18 16:02:40 +03:00
|
|
|
onSaving: async function onSaving(model, attr, options) {
|
2016-04-14 14:22:38 +03:00
|
|
|
options = options || {};
|
|
|
|
|
2020-04-29 18:44:27 +03:00
|
|
|
const self = this;
|
|
|
|
let title;
|
|
|
|
let i;
|
|
|
|
|
|
|
|
// Variables to make the slug checking more readable
|
|
|
|
const newTitle = this.get('title');
|
|
|
|
|
|
|
|
const newStatus = this.get('status');
|
|
|
|
const olderStatus = this.previous('status');
|
|
|
|
const prevTitle = this.previous('title');
|
|
|
|
const prevSlug = this.previous('slug');
|
|
|
|
const publishedAt = this.get('published_at');
|
|
|
|
const publishedAtHasChanged = this.hasDateChanged('published_at', {beforeWrite: true});
|
|
|
|
const generatedFields = ['html', 'plaintext'];
|
|
|
|
let tagsToSave;
|
|
|
|
const ops = [];
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2016-05-19 14:49:22 +03:00
|
|
|
// CASE: disallow published -> scheduled
|
|
|
|
// @TODO: remove when we have versioning based on updated_at
|
|
|
|
if (newStatus !== olderStatus && newStatus === 'scheduled' && olderStatus === 'published') {
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.ValidationError({
|
|
|
|
message: i18n.t('errors.models.post.isAlreadyPublished', {key: 'status'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-05-19 14:49:22 +03:00
|
|
|
}
|
|
|
|
|
2018-07-19 12:35:55 +03:00
|
|
|
if (options.method === 'insert') {
|
|
|
|
if (!this.get('comment_id')) {
|
|
|
|
this.set('comment_id', this.id);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-05-19 14:49:22 +03:00
|
|
|
// CASE: both page and post can get scheduled
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'scheduled') {
|
|
|
|
if (!publishedAt) {
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.ValidationError({
|
|
|
|
message: i18n.t('errors.models.post.valueCannotBeBlank', {key: 'published_at'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-04-14 14:22:38 +03:00
|
|
|
} else if (!moment(publishedAt).isValid()) {
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.ValidationError({
|
|
|
|
message: i18n.t('errors.models.post.valueCannotBeBlank', {key: 'published_at'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2017-12-12 00:47:46 +03:00
|
|
|
// CASE: to schedule/reschedule a post, a minimum diff of x minutes is needed (default configured is 2minutes)
|
2017-05-12 15:56:40 +03:00
|
|
|
} else if (
|
|
|
|
publishedAtHasChanged &&
|
|
|
|
moment(publishedAt).isBefore(moment().add(config.get('times').cannotScheduleAPostBeforeInMinutes, 'minutes')) &&
|
2018-10-06 22:27:12 +03:00
|
|
|
!options.importing &&
|
|
|
|
(!options.context || !options.context.internal)
|
2017-05-12 15:56:40 +03:00
|
|
|
) {
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.ValidationError({
|
|
|
|
message: i18n.t('errors.models.post.expectedPublishedAtInFuture', {
|
2016-09-13 18:41:14 +03:00
|
|
|
cannotScheduleAPostBeforeInMinutes: config.get('times').cannotScheduleAPostBeforeInMinutes
|
2016-05-19 14:49:22 +03:00
|
|
|
})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
2016-04-14 14:22:38 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
// CASE: detect lowercase/uppercase tag slugs
|
|
|
|
if (!_.isUndefined(this.get('tags')) && !_.isNull(this.get('tags'))) {
|
|
|
|
tagsToSave = [];
|
|
|
|
|
2016-06-02 20:11:54 +03:00
|
|
|
// and deduplicate upper/lowercase tags
|
2017-11-21 16:28:05 +03:00
|
|
|
_.each(this.get('tags'), function each(item) {
|
|
|
|
for (i = 0; i < tagsToSave.length; i = i + 1) {
|
2018-01-28 20:58:37 +03:00
|
|
|
if (tagsToSave[i].name && item.name && tagsToSave[i].name.toLocaleLowerCase() === item.name.toLocaleLowerCase()) {
|
2016-06-02 20:11:54 +03:00
|
|
|
return;
|
|
|
|
}
|
2014-03-24 22:08:06 +04:00
|
|
|
}
|
2014-05-23 23:32:14 +04:00
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
tagsToSave.push(item);
|
2016-06-02 20:11:54 +03:00
|
|
|
});
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
this.set('tags', tagsToSave);
|
2016-06-02 20:11:54 +03:00
|
|
|
}
|
2014-02-19 17:57:26 +04:00
|
|
|
|
2019-09-16 11:45:55 +03:00
|
|
|
/**
|
|
|
|
* CASE: Attach id to update existing posts_meta entry for a post
|
|
|
|
* CASE: Don't create new posts_meta entry if post meta is empty
|
|
|
|
*/
|
|
|
|
if (!_.isUndefined(this.get('posts_meta')) && !_.isNull(this.get('posts_meta'))) {
|
|
|
|
let postsMetaData = this.get('posts_meta');
|
|
|
|
let relatedModelId = model.related('posts_meta').get('id');
|
|
|
|
let hasNoData = !_.values(postsMetaData).some(x => !!x);
|
|
|
|
if (relatedModelId && !_.isEmpty(postsMetaData)) {
|
|
|
|
postsMetaData.id = relatedModelId;
|
|
|
|
this.set('posts_meta', postsMetaData);
|
|
|
|
} else if (_.isEmpty(postsMetaData) || hasNoData) {
|
|
|
|
this.set('posts_meta', null);
|
|
|
|
}
|
|
|
|
}
|
2019-09-17 15:12:25 +03:00
|
|
|
|
2019-01-08 12:48:53 +03:00
|
|
|
this.handleAttachedModels(model);
|
|
|
|
|
2019-02-07 12:59:37 +03:00
|
|
|
ghostBookshelf.Model.prototype.onSaving.apply(this, arguments);
|
2013-08-25 14:49:31 +04:00
|
|
|
|
2018-04-10 23:45:31 +03:00
|
|
|
// do not allow generated fields to be overridden via the API
|
2018-08-03 14:02:14 +03:00
|
|
|
if (!options.migrating) {
|
|
|
|
generatedFields.forEach((field) => {
|
|
|
|
if (this.hasChanged(field)) {
|
|
|
|
this.set(field, this.previous(field));
|
2018-05-04 16:59:39 +03:00
|
|
|
}
|
2018-08-03 14:02:14 +03:00
|
|
|
});
|
|
|
|
}
|
2018-05-04 16:59:39 +03:00
|
|
|
|
2018-08-03 14:02:14 +03:00
|
|
|
if (!this.get('mobiledoc')) {
|
2020-04-08 18:42:55 +03:00
|
|
|
this.set('mobiledoc', JSON.stringify(mobiledocLib.blankDocument));
|
2018-08-03 14:02:14 +03:00
|
|
|
}
|
2018-05-04 16:59:39 +03:00
|
|
|
|
2019-10-07 22:23:45 +03:00
|
|
|
// ensure all URLs are stored as relative
|
|
|
|
// note: html is not necessary to change because it's a generated later from mobiledoc
|
|
|
|
const urlTransformMap = {
|
|
|
|
mobiledoc: 'mobiledocAbsoluteToRelative',
|
|
|
|
custom_excerpt: 'htmlAbsoluteToRelative',
|
|
|
|
codeinjection_head: 'htmlAbsoluteToRelative',
|
|
|
|
codeinjection_foot: 'htmlAbsoluteToRelative',
|
|
|
|
feature_image: 'absoluteToRelative',
|
|
|
|
og_image: 'absoluteToRelative',
|
|
|
|
twitter_image: 'absoluteToRelative',
|
|
|
|
canonical_url: {
|
|
|
|
method: 'absoluteToRelative',
|
|
|
|
options: {
|
|
|
|
ignoreProtocol: false
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2020-06-12 19:55:40 +03:00
|
|
|
Object.entries(urlTransformMap).forEach(([attrToTransform, transform]) => {
|
2019-10-07 22:23:45 +03:00
|
|
|
let method = transform;
|
2020-06-12 19:55:40 +03:00
|
|
|
let transformOptions = {};
|
2019-10-07 22:23:45 +03:00
|
|
|
|
|
|
|
if (typeof transform === 'object') {
|
|
|
|
method = transform.method;
|
2020-06-12 19:55:40 +03:00
|
|
|
transformOptions = transform.options || {};
|
2019-10-07 22:23:45 +03:00
|
|
|
}
|
|
|
|
|
2020-06-12 19:55:40 +03:00
|
|
|
if (this.hasChanged(attrToTransform) && this.get(attrToTransform)) {
|
|
|
|
const transformedValue = urlUtils[method](this.get(attrToTransform), transformOptions);
|
|
|
|
this.set(attrToTransform, transformedValue);
|
2019-10-07 22:23:45 +03:00
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2020-06-17 15:12:32 +03:00
|
|
|
// If we're force re-rendering we want to make sure that all image cards
|
|
|
|
// have original dimensions stored in the payload for use by card renderers
|
|
|
|
if (options.force_rerender) {
|
2020-06-18 16:02:40 +03:00
|
|
|
this.set('mobiledoc', await mobiledocLib.populateImageSizes(this.get('mobiledoc')));
|
2020-06-17 15:12:32 +03:00
|
|
|
}
|
|
|
|
|
2019-02-24 00:02:42 +03:00
|
|
|
// CASE: mobiledoc has changed, generate html
|
2020-06-12 20:05:57 +03:00
|
|
|
// CASE: ?force_rerender=true passed via Admin API
|
2019-02-24 00:02:42 +03:00
|
|
|
// CASE: html is null, but mobiledoc exists (only important for migrations & importing)
|
2020-06-12 20:05:57 +03:00
|
|
|
if (
|
|
|
|
this.hasChanged('mobiledoc')
|
|
|
|
|| options.force_rerender
|
|
|
|
|| (!this.get('html') && (options.migrating || options.importing))
|
|
|
|
) {
|
2019-01-31 15:33:05 +03:00
|
|
|
try {
|
2020-04-08 20:21:15 +03:00
|
|
|
this.set('html', mobiledocLib.mobiledocHtmlRenderer.render(JSON.parse(this.get('mobiledoc'))));
|
2019-01-31 15:33:05 +03:00
|
|
|
} catch (err) {
|
2020-05-22 21:22:20 +03:00
|
|
|
throw new errors.ValidationError({
|
2019-01-31 15:33:05 +03:00
|
|
|
message: 'Invalid mobiledoc structure.',
|
2019-07-22 13:17:50 +03:00
|
|
|
help: 'https://ghost.org/docs/concepts/posts/'
|
2019-01-31 15:33:05 +03:00
|
|
|
});
|
|
|
|
}
|
2016-09-26 16:23:49 +03:00
|
|
|
}
|
2017-04-11 11:55:36 +03:00
|
|
|
|
replace custom showdown fork with markdown-it (#8451)
refs https://github.com/TryGhost/Ghost-Admin/pull/690, closes #1501, closes #2093, closes #4592, closes #4627, closes #4659, closes #5039, closes #5237, closes #5587, closes #5625, closes #5632, closes #5822, closes #5939, closes #6840, closes #7183, closes #7536
- replace custom showdown fork with markdown-it
- swaps showdown for markdown-it when rendering markdown
- match existing header ID behaviour
- allow headers without a space after the #s
- add duplicate header ID handling
- remove legacy markdown spec
- move markdown-it setup into markdown-converter util
- update mobiledoc specs to match markdown-it newline behaviour
- update data-generator HTML to match markdown-it newline behaviour
- fix Post "converts html to plaintext" test
- update rss spec to match markdown-it newline behaviour
- close almost all related showdown bugs
2017-05-15 19:48:14 +03:00
|
|
|
if (this.hasChanged('html') || !this.get('plaintext')) {
|
2020-07-15 08:41:24 +03:00
|
|
|
let plaintext;
|
|
|
|
|
|
|
|
if (this.get('html') === null) {
|
|
|
|
plaintext = null;
|
|
|
|
} else {
|
|
|
|
plaintext = htmlToText.fromString(this.get('html'), {
|
|
|
|
wordwrap: 80,
|
|
|
|
ignoreImage: true,
|
|
|
|
hideLinkHrefIfSameAsText: true,
|
|
|
|
preserveNewlines: true,
|
|
|
|
returnDomByDefault: true,
|
|
|
|
uppercaseHeadings: false
|
|
|
|
});
|
|
|
|
}
|
2019-02-01 01:14:12 +03:00
|
|
|
|
|
|
|
// CASE: html is e.g. <p></p>
|
|
|
|
// @NOTE: Otherwise we will always update the resource to `plaintext: ''` and Bookshelf thinks that this
|
|
|
|
// value was modified.
|
2019-03-04 17:03:44 +03:00
|
|
|
if (plaintext || plaintext !== this.get('plaintext')) {
|
2019-02-01 01:14:12 +03:00
|
|
|
this.set('plaintext', plaintext);
|
|
|
|
}
|
2017-04-11 11:55:36 +03:00
|
|
|
}
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2014-01-07 00:17:20 +04:00
|
|
|
// disabling sanitization until we can implement a better version
|
2017-05-23 19:18:13 +03:00
|
|
|
if (!options.importing) {
|
2020-05-22 21:22:20 +03:00
|
|
|
title = this.get('title') || i18n.t('errors.models.post.untitled');
|
2017-05-23 19:18:13 +03:00
|
|
|
this.set('title', _.toString(title).trim());
|
|
|
|
}
|
2013-08-30 08:18:55 +04:00
|
|
|
|
2015-09-25 19:11:22 +03:00
|
|
|
// ### Business logic for published_at and published_by
|
|
|
|
// If the current status is 'published' and published_at is not set, set it to now
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'published' && !publishedAt) {
|
2015-09-25 19:11:22 +03:00
|
|
|
this.set('published_at', new Date());
|
|
|
|
}
|
2015-02-22 00:04:00 +03:00
|
|
|
|
2015-09-25 19:11:22 +03:00
|
|
|
// If the current status is 'published' and the status has just changed ensure published_by is set correctly
|
2016-04-14 14:22:38 +03:00
|
|
|
if (newStatus === 'published' && this.hasChanged('status')) {
|
2015-02-22 00:04:00 +03:00
|
|
|
// unless published_by is set and we're importing, set published_by to contextUser
|
|
|
|
if (!(this.get('published_by') && options.importing)) {
|
2019-02-24 00:00:24 +03:00
|
|
|
this.set('published_by', String(this.contextUser(options)));
|
2014-08-09 23:16:54 +04:00
|
|
|
}
|
2015-09-25 19:11:22 +03:00
|
|
|
} else {
|
|
|
|
// In any other case (except import), `published_by` should not be changed
|
|
|
|
if (this.hasChanged('published_by') && !options.importing) {
|
2019-02-24 00:00:24 +03:00
|
|
|
this.set('published_by', this.previous('published_by') ? String(this.previous('published_by')) : null);
|
2015-09-25 19:11:22 +03:00
|
|
|
}
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
2013-06-15 20:11:15 +04:00
|
|
|
|
2020-11-06 20:32:23 +03:00
|
|
|
// email_recipient_filter is read-only and should only be set using a query param when publishing/scheduling
|
2020-11-17 14:00:03 +03:00
|
|
|
if (options.email_recipient_filter && options.email_recipient_filter !== 'none' && this.hasChanged('status') && (newStatus === 'published' || newStatus === 'scheduled')) {
|
|
|
|
this.set('email_recipient_filter', options.email_recipient_filter);
|
2019-11-14 20:29:03 +03:00
|
|
|
}
|
|
|
|
|
2020-11-06 20:32:23 +03:00
|
|
|
// ensure draft posts have the email_recipient_filter reset unless an email has already been sent
|
2019-11-14 20:29:03 +03:00
|
|
|
if (newStatus === 'draft' && this.hasChanged('status')) {
|
|
|
|
ops.push(function ensureSendEmailWhenPublishedIsUnchanged() {
|
2019-11-15 18:11:55 +03:00
|
|
|
return self.related('email').fetch({transacting: options.transacting}).then((email) => {
|
2020-11-06 20:32:23 +03:00
|
|
|
if (!email) {
|
|
|
|
self.set('email_recipient_filter', 'none');
|
2019-11-14 20:29:03 +03:00
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2016-03-23 16:17:01 +03:00
|
|
|
// If a title is set, not the same as the old title, a draft post, and has never been published
|
2016-04-14 14:22:38 +03:00
|
|
|
if (prevTitle !== undefined && newTitle !== prevTitle && newStatus === 'draft' && !publishedAt) {
|
2017-04-19 16:53:23 +03:00
|
|
|
ops.push(function updateSlug() {
|
|
|
|
// Pass the new slug through the generator to strip illegal characters, detect duplicates
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, self.get('title'),
|
2015-09-23 13:54:56 +03:00
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing})
|
2017-04-19 16:53:23 +03:00
|
|
|
.then(function then(slug) {
|
|
|
|
// After the new slug is found, do another generate for the old title to compare it to the old slug
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, prevTitle,
|
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing}
|
2020-06-12 19:55:40 +03:00
|
|
|
).then(function prevTitleSlugGenerated(prevTitleSlug) {
|
2017-04-19 16:53:23 +03:00
|
|
|
// If the old slug is the same as the slug that was generated from the old title
|
|
|
|
// then set a new slug. If it is not the same, means was set by the user
|
|
|
|
if (prevTitleSlug === prevSlug) {
|
|
|
|
self.set({slug: slug});
|
|
|
|
}
|
|
|
|
});
|
2016-03-23 16:17:01 +03:00
|
|
|
});
|
2017-04-19 16:53:23 +03:00
|
|
|
});
|
2016-03-23 16:17:01 +03:00
|
|
|
} else {
|
2017-04-19 16:53:23 +03:00
|
|
|
ops.push(function updateSlug() {
|
|
|
|
// If any of the attributes above were false, set initial slug and check to see if slug was changed by the user
|
|
|
|
if (self.hasChanged('slug') || !self.get('slug')) {
|
|
|
|
// Pass the new slug through the generator to strip illegal characters, detect duplicates
|
|
|
|
return ghostBookshelf.Model.generateSlug(Post, self.get('slug') || self.get('title'),
|
2016-03-23 16:17:01 +03:00
|
|
|
{status: 'all', transacting: options.transacting, importing: options.importing})
|
2017-04-19 16:53:23 +03:00
|
|
|
.then(function then(slug) {
|
|
|
|
self.set({slug: slug});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return Promise.resolve();
|
|
|
|
});
|
2013-09-14 23:01:46 +04:00
|
|
|
}
|
2017-04-19 16:53:23 +03:00
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
// CASE: Handle mobiledoc backups/revisions. This is a pure database feature.
|
|
|
|
if (model.hasChanged('mobiledoc') && !options.importing && !options.migrating) {
|
|
|
|
ops.push(function updateRevisions() {
|
|
|
|
return ghostBookshelf.model('MobiledocRevision')
|
|
|
|
.findAll(Object.assign({
|
|
|
|
filter: `post_id:${model.id}`,
|
|
|
|
columns: ['id']
|
|
|
|
}, _.pick(options, 'transacting')))
|
|
|
|
.then((revisions) => {
|
|
|
|
/**
|
|
|
|
* Store prev + latest mobiledoc content, because we have decided against a migration, which
|
|
|
|
* iterates over all posts and creates a copy of the current mobiledoc content.
|
|
|
|
*
|
|
|
|
* Reasons:
|
|
|
|
* - usually migrations for the post table are slow and error-prone
|
|
|
|
* - there is no need to create a copy for all posts now, because we only want to ensure
|
|
|
|
* that posts, which you are currently working on, are getting a content backup
|
|
|
|
* - no need to create revisions for existing published posts
|
|
|
|
*
|
|
|
|
* The feature is very minimal in the beginning. As soon as you update to this Ghost version,
|
|
|
|
* you
|
|
|
|
*/
|
|
|
|
if (!revisions.length && options.method !== 'insert') {
|
|
|
|
model.set('mobiledoc_revisions', [{
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.previous('mobiledoc'),
|
|
|
|
created_at_ts: Date.now() - 1
|
|
|
|
}, {
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.get('mobiledoc'),
|
|
|
|
created_at_ts: Date.now()
|
|
|
|
}]);
|
|
|
|
} else {
|
|
|
|
const revisionsJSON = revisions.toJSON().slice(0, MOBILEDOC_REVISIONS_COUNT - 1);
|
|
|
|
|
|
|
|
model.set('mobiledoc_revisions', revisionsJSON.concat([{
|
|
|
|
post_id: model.id,
|
|
|
|
mobiledoc: model.get('mobiledoc'),
|
|
|
|
created_at_ts: Date.now()
|
|
|
|
}]));
|
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
return sequence(ops);
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
created_by: function createdBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'created_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
updated_by: function updatedBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'updated_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
published_by: function publishedBy() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.belongsTo('User', 'published_by');
|
2014-04-27 20:58:34 +04:00
|
|
|
},
|
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
authors: function authors() {
|
|
|
|
return this.belongsToMany('User', 'posts_authors', 'post_id', 'author_id')
|
|
|
|
.withPivot('sort_order')
|
|
|
|
.query('orderBy', 'sort_order', 'ASC');
|
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
tags: function tags() {
|
2018-02-20 10:49:00 +03:00
|
|
|
return this.belongsToMany('Tag', 'posts_tags', 'post_id', 'tag_id')
|
|
|
|
.withPivot('sort_order')
|
|
|
|
.query('orderBy', 'sort_order', 'ASC');
|
2014-02-25 00:28:18 +04:00
|
|
|
},
|
|
|
|
|
2015-06-14 18:58:49 +03:00
|
|
|
fields: function fields() {
|
2014-07-13 15:17:18 +04:00
|
|
|
return this.morphMany('AppField', 'relatable');
|
2014-04-22 05:08:11 +04:00
|
|
|
},
|
2018-10-09 16:31:09 +03:00
|
|
|
|
|
|
|
mobiledoc_revisions() {
|
|
|
|
return this.hasMany('MobiledocRevision', 'post_id');
|
|
|
|
},
|
|
|
|
|
2019-09-16 11:45:55 +03:00
|
|
|
posts_meta: function postsMeta() {
|
|
|
|
return this.hasOne('PostsMeta', 'post_id');
|
|
|
|
},
|
|
|
|
|
2019-11-07 11:52:01 +03:00
|
|
|
email: function email() {
|
2019-11-06 12:30:11 +03:00
|
|
|
return this.hasOne('Email', 'post_id');
|
|
|
|
},
|
|
|
|
|
2019-08-21 21:26:35 +03:00
|
|
|
/**
|
|
|
|
* @NOTE:
|
|
|
|
* If you are requesting models with `columns`, you try to only receive some fields of the model/s.
|
|
|
|
* But the model layer is complex and needs specific fields in specific situations.
|
|
|
|
*
|
|
|
|
* ### url generation was removed but default columns need to be checked before removal
|
|
|
|
* - @TODO: with dynamic routing, we no longer need default columns to fetch
|
|
|
|
* - because with static routing Ghost generated the url on runtime and needed the following attributes:
|
|
|
|
* - `slug`: /:slug/
|
|
|
|
* - `published_at`: /:year/:slug
|
|
|
|
* - `author_id`: /:author/:slug, /:primary_author/:slug
|
|
|
|
* - now, the UrlService pre-generates urls based on the resources
|
|
|
|
* - you can ask `urlService.getUrlByResourceId(post.id)`
|
|
|
|
*
|
|
|
|
* ### events
|
|
|
|
* - you call `findAll` with `columns: id`
|
|
|
|
* - then you trigger `post.save()` on the response
|
|
|
|
* - bookshelf events (`onSaving`) and model events (`emitChange`) are triggered
|
|
|
|
* - but you only fetched the id column, this will trouble (!), because the event hooks require more
|
|
|
|
* data than just the id
|
|
|
|
* - @TODO: we need to disallow this (!)
|
|
|
|
* - you should use `models.Post.edit(..)`
|
|
|
|
* - this disallows using the `columns` option
|
|
|
|
* - same for destroy - you should use `models.Post.destroy(...)`
|
|
|
|
*
|
|
|
|
* @IMPORTANT: This fn should **never** be used when updating models (models.Post.edit)!
|
|
|
|
* Because the events for updating a resource require most of the fields.
|
|
|
|
* This is protected by the fn `permittedOptions`.
|
|
|
|
*/
|
|
|
|
defaultColumnsToFetch: function defaultColumnsToFetch() {
|
|
|
|
return ['id', 'published_at', 'slug', 'author_id'];
|
|
|
|
},
|
2017-05-30 13:40:39 +03:00
|
|
|
/**
|
|
|
|
* If the `formats` option is not used, we return `html` be default.
|
|
|
|
* Otherwise we return what is requested e.g. `?formats=mobiledoc,plaintext`
|
|
|
|
*/
|
|
|
|
formatsToJSON: function formatsToJSON(attrs, options) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const defaultFormats = ['html'];
|
|
|
|
const formatsToKeep = options.formats || defaultFormats;
|
2017-05-30 13:40:39 +03:00
|
|
|
|
|
|
|
// Iterate over all known formats, and if they are not in the keep list, remove them
|
|
|
|
_.each(Post.allowedFormats, function (format) {
|
|
|
|
if (formatsToKeep.indexOf(format) === -1) {
|
|
|
|
delete attrs[format];
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
|
|
|
return attrs;
|
|
|
|
},
|
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
|
|
|
toJSON: function toJSON(unfilteredOptions) {
|
2020-04-29 18:44:27 +03:00
|
|
|
const options = Post.filterOptions(unfilteredOptions, 'toJSON');
|
|
|
|
let attrs = ghostBookshelf.Model.prototype.toJSON.call(this, options);
|
2014-04-22 05:08:11 +04:00
|
|
|
|
2017-05-30 13:40:39 +03:00
|
|
|
attrs = this.formatsToJSON(attrs, options);
|
|
|
|
|
2018-10-09 16:31:09 +03:00
|
|
|
// CASE: never expose the revisions
|
|
|
|
delete attrs.mobiledoc_revisions;
|
|
|
|
|
2017-07-31 12:00:03 +03:00
|
|
|
// If the current column settings allow it...
|
|
|
|
if (!options.columns || (options.columns && options.columns.indexOf('primary_tag') > -1)) {
|
2017-08-24 15:07:19 +03:00
|
|
|
// ... attach a computed property of primary_tag which is the first tag if it is public, else null
|
|
|
|
if (attrs.tags && attrs.tags.length > 0 && attrs.tags[0].visibility === 'public') {
|
|
|
|
attrs.primary_tag = attrs.tags[0];
|
|
|
|
} else {
|
|
|
|
attrs.primary_tag = null;
|
|
|
|
}
|
2017-07-31 12:00:03 +03:00
|
|
|
}
|
2015-07-04 21:27:23 +03:00
|
|
|
|
2014-04-22 05:08:11 +04:00
|
|
|
return attrs;
|
2015-11-11 20:52:44 +03:00
|
|
|
},
|
2020-07-14 14:48:36 +03:00
|
|
|
|
|
|
|
// NOTE: overloads models base method to take `post_meta` changes into account
|
|
|
|
wasChanged() {
|
|
|
|
if (!this._changed) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
const postMetaChanged = this.relations.posts_meta && this.relations.posts_meta._changed && Object.keys(this.relations.posts_meta._changed).length;
|
|
|
|
|
|
|
|
if (!Object.keys(this._changed).length && !postMetaChanged) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
},
|
|
|
|
|
2018-01-25 19:54:28 +03:00
|
|
|
enforcedFilters: function enforcedFilters(options) {
|
|
|
|
return options.context && options.context.public ? 'status:published' : null;
|
2015-11-11 20:52:44 +03:00
|
|
|
},
|
2020-07-14 14:48:36 +03:00
|
|
|
|
2018-01-25 19:54:28 +03:00
|
|
|
defaultFilters: function defaultFilters(options) {
|
|
|
|
if (options.context && options.context.internal) {
|
2016-04-14 18:54:49 +03:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
2019-09-16 13:51:54 +03:00
|
|
|
return options.context && options.context.public ? 'type:post' : 'type:post+status:published';
|
2018-11-15 17:53:24 +03:00
|
|
|
},
|
|
|
|
|
|
|
|
/**
|
2019-09-17 15:12:25 +03:00
|
|
|
* You can pass an extra `status=VALUES` field.
|
2018-11-15 17:53:24 +03:00
|
|
|
* Long-Term: We should deprecate these short cuts and force users to use the filter param.
|
|
|
|
*/
|
|
|
|
extraFilters: function extraFilters(options) {
|
2019-09-17 15:12:25 +03:00
|
|
|
if (!options.status) {
|
2018-11-15 17:53:24 +03:00
|
|
|
return null;
|
|
|
|
}
|
|
|
|
|
|
|
|
let filter = null;
|
|
|
|
|
|
|
|
// CASE: "status" is passed, combine filters
|
|
|
|
if (options.status && options.status !== 'all') {
|
|
|
|
options.status = _.includes(ALL_STATUSES, options.status) ? options.status : 'published';
|
|
|
|
|
|
|
|
if (!filter) {
|
|
|
|
filter = `status:${options.status}`;
|
|
|
|
} else {
|
|
|
|
filter = `${filter}+status:${options.status}`;
|
|
|
|
}
|
|
|
|
} else if (options.status === 'all') {
|
|
|
|
if (!filter) {
|
|
|
|
filter = `status:[${ALL_STATUSES}]`;
|
|
|
|
} else {
|
|
|
|
filter = `${filter}+status:[${ALL_STATUSES}]`;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
delete options.status;
|
|
|
|
return filter;
|
2019-01-29 21:44:52 +03:00
|
|
|
},
|
|
|
|
|
2019-02-07 00:05:03 +03:00
|
|
|
getAction(event, options) {
|
2019-01-29 21:44:52 +03:00
|
|
|
const actor = this.getActor(options);
|
|
|
|
|
|
|
|
// @NOTE: we ignore internal updates (`options.context.internal`) for now
|
|
|
|
if (!actor) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// @TODO: implement context
|
|
|
|
return {
|
2019-02-07 00:05:03 +03:00
|
|
|
event: event,
|
2019-01-29 21:44:52 +03:00
|
|
|
resource_id: this.id || this.previous('id'),
|
2019-08-14 05:40:17 +03:00
|
|
|
resource_type: 'post',
|
2019-01-29 21:44:52 +03:00
|
|
|
actor_id: actor.id,
|
|
|
|
actor_type: actor.type
|
|
|
|
};
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
}, {
|
2018-07-19 12:35:55 +03:00
|
|
|
allowedFormats: ['mobiledoc', 'html', 'plaintext'],
|
2017-05-30 13:40:39 +03:00
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
orderDefaultOptions: function orderDefaultOptions() {
|
|
|
|
return {
|
|
|
|
status: 'ASC',
|
|
|
|
published_at: 'DESC',
|
|
|
|
updated_at: 'DESC',
|
|
|
|
id: 'DESC'
|
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2018-11-15 17:27:31 +03:00
|
|
|
orderDefaultRaw: function (options) {
|
|
|
|
let order = '' +
|
2016-07-15 13:04:10 +03:00
|
|
|
'CASE WHEN posts.status = \'scheduled\' THEN 1 ' +
|
|
|
|
'WHEN posts.status = \'draft\' THEN 2 ' +
|
|
|
|
'ELSE 3 END ASC,' +
|
2018-09-04 14:28:11 +03:00
|
|
|
'CASE WHEN posts.status != \'draft\' THEN posts.published_at END DESC,' +
|
2016-07-15 13:04:10 +03:00
|
|
|
'posts.updated_at DESC,' +
|
|
|
|
'posts.id DESC';
|
2018-11-15 17:27:31 +03:00
|
|
|
|
|
|
|
// CASE: if the filter contains an `IN` operator, we should return the posts first, which match both tags
|
|
|
|
if (options.filter && options.filter.match(/(tags|tag):\s?\[.*\]/)) {
|
🐛 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
|
|
|
order = `(SELECT count(*) FROM posts_tags WHERE post_id = posts.id) DESC, ${order}`;
|
2018-11-15 17:27:31 +03:00
|
|
|
}
|
|
|
|
|
2018-11-15 18:17:51 +03:00
|
|
|
// CASE: if the filter contains an `IN` operator, we should return the posts first, which match both authors
|
|
|
|
if (options.filter && options.filter.match(/(authors|author):\s?\[.*\]/)) {
|
🐛 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
|
|
|
order = `(SELECT count(*) FROM posts_authors WHERE post_id = posts.id) DESC, ${order}`;
|
2018-11-15 18:17:51 +03:00
|
|
|
}
|
|
|
|
|
2018-11-15 17:27:31 +03:00
|
|
|
return order;
|
2016-07-15 13:04:10 +03:00
|
|
|
},
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
/**
|
2017-12-12 00:47:46 +03:00
|
|
|
* Returns an array of keys permitted in a method's `options` hash, depending on the current method.
|
|
|
|
* @param {String} methodName The name of the method to check valid options for.
|
|
|
|
* @return {Array} Keys allowed in the `options` hash of the model's method.
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
permittedOptions: function permittedOptions(methodName) {
|
2020-04-29 18:44:27 +03:00
|
|
|
let options = ghostBookshelf.Model.permittedOptions.call(this, methodName);
|
|
|
|
|
|
|
|
// whitelists for the `options` hash argument on methods, by method name.
|
|
|
|
// these are the only options that can be passed to Bookshelf / Knex.
|
|
|
|
const validOptions = {
|
|
|
|
findOne: ['columns', 'importing', 'withRelated', 'require', 'filter'],
|
|
|
|
findPage: ['status'],
|
|
|
|
findAll: ['columns', 'filter'],
|
|
|
|
destroy: ['destroyAll', 'destroyBy'],
|
2020-11-06 20:32:23 +03:00
|
|
|
edit: ['filter', 'email_recipient_filter', 'force_rerender']
|
2020-04-29 18:44:27 +03:00
|
|
|
};
|
2014-05-06 05:45:08 +04:00
|
|
|
|
2017-05-30 13:40:39 +03:00
|
|
|
// The post model additionally supports having a formats option
|
|
|
|
options.push('formats');
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
if (validOptions[methodName]) {
|
|
|
|
options = options.concat(validOptions[methodName]);
|
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
},
|
|
|
|
|
2018-04-15 13:12:20 +03:00
|
|
|
/**
|
|
|
|
* We have to ensure consistency. If you listen on model events (e.g. `post.published`), you can expect that you always
|
|
|
|
* receive all fields including relations. Otherwise you can't rely on a consistent flow. And we want to avoid
|
|
|
|
* that event listeners have to re-fetch a resource. This function is used in the context of inserting
|
|
|
|
* and updating resources. We won't return the relations by default for now.
|
2019-09-17 15:12:25 +03:00
|
|
|
*
|
2019-09-16 11:45:55 +03:00
|
|
|
* We also always fetch posts metadata to keep current behavior consistent
|
2018-04-15 13:12:20 +03:00
|
|
|
*/
|
|
|
|
defaultRelations: function defaultRelations(methodName, options) {
|
2019-01-08 12:48:53 +03:00
|
|
|
if (['edit', 'add', 'destroy'].indexOf(methodName) !== -1) {
|
2018-10-11 10:04:47 +03:00
|
|
|
options.withRelated = _.union(['authors', 'tags'], options.withRelated || []);
|
2018-04-15 13:12:20 +03:00
|
|
|
}
|
2020-01-06 17:38:40 +03:00
|
|
|
|
|
|
|
const META_ATTRIBUTES = _.without(ghostBookshelf.model('PostsMeta').prototype.permittedAttributes(), 'id', 'post_id');
|
|
|
|
|
|
|
|
// NOTE: only include post_meta relation when requested in 'columns' or by default
|
|
|
|
// optimization is needed to be able to perform .findAll on large SQLite datasets
|
|
|
|
if (!options.columns || (options.columns && _.intersection(META_ATTRIBUTES, options.columns).length)) {
|
|
|
|
options.withRelated = _.union(['posts_meta'], options.withRelated || []);
|
|
|
|
}
|
2018-04-15 13:12:20 +03:00
|
|
|
|
|
|
|
return options;
|
|
|
|
},
|
|
|
|
|
2014-05-06 05:45:08 +04:00
|
|
|
/**
|
2017-04-19 11:59:09 +03:00
|
|
|
* Manually add 'tags' attribute since it's not in the schema and call parent.
|
|
|
|
*
|
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 filteredData = ghostBookshelf.Model.filterData.apply(this, arguments);
|
|
|
|
const extraData = _.pick(data, this.prototype.relationships);
|
2014-05-06 05:45:08 +04:00
|
|
|
|
2017-04-19 11:59:09 +03:00
|
|
|
_.merge(filteredData, extraData);
|
2014-05-06 05:45:08 +04:00
|
|
|
return filteredData;
|
|
|
|
},
|
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
|
|
|
|
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
|
|
|
// ## Model Data Functions
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Find One
|
|
|
|
* @extends ghostBookshelf.Model.findOne to handle post status
|
|
|
|
* **See:** [ghostBookshelf.Model.findOne](base.js.html#Find%20One)
|
|
|
|
*/
|
2019-02-22 14:07:34 +03:00
|
|
|
findOne: function findOne(data = {}, options = {}) {
|
|
|
|
// @TODO: remove when we drop v0.1
|
|
|
|
if (!options.filter && !data.status) {
|
|
|
|
data.status = 'published';
|
|
|
|
}
|
2013-06-09 03:39:24 +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
|
|
|
if (data.status === 'all') {
|
|
|
|
delete data.status;
|
2013-06-01 18:47:41 +04:00
|
|
|
}
|
|
|
|
|
2017-10-13 17:44:39 +03:00
|
|
|
return ghostBookshelf.Model.findOne.call(this, data, options);
|
2013-09-13 17:29:59 +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
|
|
|
|
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
|
|
|
/**
|
|
|
|
* ### Edit
|
2017-04-19 16:53:23 +03:00
|
|
|
* Fetches and saves to Post. See model.Base.edit
|
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
|
|
|
* **See:** [ghostBookshelf.Model.edit](base.js.html#edit)
|
|
|
|
*/
|
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) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'edit', {extraAllowedProperties: ['id']});
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
const editPost = () => {
|
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.forUpdate = true;
|
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
|
|
|
return ghostBookshelf.Model.edit.call(this, data, options)
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((post) => {
|
2018-04-15 13:12:20 +03:00
|
|
|
return this.findOne({
|
|
|
|
status: 'all',
|
|
|
|
id: options.id
|
|
|
|
}, _.merge({transacting: options.transacting}, unfilteredOptions))
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((found) => {
|
2017-04-19 16:53:23 +03:00
|
|
|
if (found) {
|
|
|
|
// Pass along the updated attributes for checking status changes
|
2019-01-21 23:53:11 +03:00
|
|
|
found._previousAttributes = post._previousAttributes;
|
2019-02-08 00:07:13 +03:00
|
|
|
found._changed = post._changed;
|
2020-07-14 14:48:36 +03:00
|
|
|
|
|
|
|
// NOTE: `posts_meta` fields are equivalent in terms of "wasChanged" logic to the rest of posts's table fields.
|
|
|
|
// Keeping track of them is needed to check if anything was changed in post's resource.
|
|
|
|
if (found.relations.posts_meta) {
|
|
|
|
found.relations.posts_meta._changed = post.relations.posts_meta._changed;
|
|
|
|
}
|
|
|
|
|
2017-04-19 16:53:23 +03:00
|
|
|
return found;
|
|
|
|
}
|
|
|
|
});
|
|
|
|
});
|
2017-11-21 16:28:05 +03:00
|
|
|
};
|
2014-02-19 17:57:26 +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
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
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.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
return editPost();
|
|
|
|
});
|
2017-04-19 16:53:23 +03:00
|
|
|
}
|
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
return editPost();
|
2013-11-03 21:13:19 +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
|
|
|
|
|
|
|
/**
|
|
|
|
* ### Add
|
|
|
|
* @extends ghostBookshelf.Model.add to handle returning the full object
|
|
|
|
* **See:** [ghostBookshelf.Model.add](base.js.html#add)
|
|
|
|
*/
|
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) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'add', {extraAllowedProperties: ['id']});
|
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
|
|
|
|
2017-11-21 16:28:05 +03:00
|
|
|
const addPost = (() => {
|
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 ghostBookshelf.Model.add.call(this, data, options)
|
2017-11-21 16:28:05 +03:00
|
|
|
.then((post) => {
|
2018-04-15 13:12:20 +03:00
|
|
|
return this.findOne({
|
|
|
|
status: 'all',
|
|
|
|
id: post.id
|
|
|
|
}, _.merge({transacting: options.transacting}, unfilteredOptions));
|
2017-11-21 16:28:05 +03:00
|
|
|
});
|
2013-09-13 17:29:59 +04:00
|
|
|
});
|
2017-11-21 16:28:05 +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
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
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.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
return addPost();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return addPost();
|
|
|
|
},
|
|
|
|
|
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) {
|
|
|
|
let options = this.filterOptions(unfilteredOptions, 'destroy', {extraAllowedProperties: ['id']});
|
2017-11-21 16:28:05 +03:00
|
|
|
|
|
|
|
const destroyPost = () => {
|
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 ghostBookshelf.Model.destroy.call(this, options);
|
2017-11-21 16:28:05 +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
|
|
|
if (!options.transacting) {
|
2017-11-21 16:28:05 +03:00
|
|
|
return ghostBookshelf.transaction((transacting) => {
|
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.transacting = transacting;
|
2017-11-21 16:28:05 +03:00
|
|
|
return destroyPost();
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
|
|
|
return destroyPost();
|
2013-09-27 14:56:20 +04:00
|
|
|
},
|
2014-04-03 17:03:09 +04:00
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
// NOTE: the `authors` extension is the parent of the post model. It also has a permissible function.
|
2020-03-19 18:23:10 +03:00
|
|
|
permissible: function permissible(postModel, action, context, unsafeAttrs, loadedPermissions, hasUserPermission, hasApiKeyPermission) {
|
2019-10-08 16:44:27 +03:00
|
|
|
let isContributor;
|
|
|
|
let isOwner;
|
|
|
|
let isAdmin;
|
|
|
|
let isEditor;
|
|
|
|
let isIntegration;
|
|
|
|
let isEdit;
|
|
|
|
let isAdd;
|
|
|
|
let isDestroy;
|
2018-02-21 18:59:48 +03:00
|
|
|
|
2017-09-27 14:12:53 +03:00
|
|
|
function isChanging(attr) {
|
|
|
|
return unsafeAttrs[attr] && unsafeAttrs[attr] !== postModel.get(attr);
|
|
|
|
}
|
|
|
|
|
2018-02-07 12:46:22 +03:00
|
|
|
function isPublished() {
|
|
|
|
return unsafeAttrs.status && unsafeAttrs.status !== 'draft';
|
|
|
|
}
|
|
|
|
|
|
|
|
function isDraft() {
|
|
|
|
return postModel.get('status') === 'draft';
|
|
|
|
}
|
|
|
|
|
|
|
|
isContributor = loadedPermissions.user && _.some(loadedPermissions.user.roles, {name: 'Contributor'});
|
2019-10-08 16:44:27 +03:00
|
|
|
isOwner = loadedPermissions.user && _.some(loadedPermissions.user.roles, {name: 'Owner'});
|
2020-05-20 08:47:27 +03:00
|
|
|
isAdmin = loadedPermissions.user && _.some(loadedPermissions.user.roles, {name: 'Administrator'});
|
2019-10-08 16:44:27 +03:00
|
|
|
isEditor = loadedPermissions.user && _.some(loadedPermissions.user.roles, {name: 'Editor'});
|
|
|
|
isIntegration = loadedPermissions.apiKey && _.some(loadedPermissions.apiKey.roles, {name: 'Admin Integration'});
|
|
|
|
|
2018-02-07 12:46:22 +03:00
|
|
|
isEdit = (action === 'edit');
|
|
|
|
isAdd = (action === 'add');
|
|
|
|
isDestroy = (action === 'destroy');
|
|
|
|
|
|
|
|
if (isContributor && isEdit) {
|
2018-03-27 17:16:15 +03:00
|
|
|
// Only allow contributor edit if status is changing, and the post is a draft post
|
|
|
|
hasUserPermission = !isChanging('status') && isDraft();
|
2018-02-07 12:46:22 +03:00
|
|
|
} else if (isContributor && isAdd) {
|
|
|
|
// If adding, make sure it's a draft post and has the correct ownership
|
2018-03-27 17:16:15 +03:00
|
|
|
hasUserPermission = !isPublished();
|
2018-02-07 12:46:22 +03:00
|
|
|
} else if (isContributor && isDestroy) {
|
|
|
|
// If destroying, only allow contributor to destroy their own draft posts
|
2018-03-27 17:16:15 +03:00
|
|
|
hasUserPermission = isDraft();
|
2019-10-08 16:44:27 +03:00
|
|
|
} else if (!(isOwner || isAdmin || isEditor || isIntegration)) {
|
|
|
|
hasUserPermission = !isChanging('visibility');
|
2018-02-07 12:46:22 +03:00
|
|
|
}
|
|
|
|
|
2018-10-09 14:03:13 +03:00
|
|
|
const excludedAttrs = [];
|
2018-02-07 12:46:22 +03:00
|
|
|
if (isContributor) {
|
|
|
|
// Note: at the moment primary_tag is a computed field,
|
2018-03-27 17:16:15 +03:00
|
|
|
// meaning we don't add it to this list. However, if the primary_tag/primary_author
|
2018-02-07 12:46:22 +03:00
|
|
|
// ever becomes a db field rather than a computed field, add it to this list
|
2018-03-27 17:16:15 +03:00
|
|
|
// TODO: once contributors are able to edit existing tags, this can be removed
|
|
|
|
// @TODO: we need a concept for making a diff between incoming tags and existing tags
|
2018-10-09 14:03:13 +03:00
|
|
|
excludedAttrs.push('tags');
|
2014-05-14 05:49:07 +04:00
|
|
|
}
|
|
|
|
|
2020-03-19 18:23:10 +03:00
|
|
|
if (hasUserPermission && hasApiKeyPermission) {
|
2018-10-09 14:03:13 +03:00
|
|
|
return Promise.resolve({excludedAttrs});
|
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
|
|
|
}
|
|
|
|
|
2020-05-22 21:22:20 +03:00
|
|
|
return Promise.reject(new errors.NoPermissionError({
|
|
|
|
message: i18n.t('errors.models.post.notEnoughPermission')
|
2018-03-27 17:16:15 +03:00
|
|
|
}));
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
});
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2013-09-23 02:20:08 +04:00
|
|
|
Posts = ghostBookshelf.Collection.extend({
|
2015-12-02 13:06:44 +03:00
|
|
|
model: Post
|
2013-06-25 15:43:15 +04:00
|
|
|
});
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
// Extension for handling the logic for author + multiple authors
|
|
|
|
Post = relations.authors.extendModel(Post, Posts, ghostBookshelf);
|
|
|
|
|
2013-06-25 15:43:15 +04:00
|
|
|
module.exports = {
|
2014-07-13 15:17:18 +04:00
|
|
|
Post: ghostBookshelf.model('Post', Post),
|
|
|
|
Posts: ghostBookshelf.collection('Posts', Posts)
|
2014-02-25 14:18:33 +04:00
|
|
|
};
|