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
|
2017-11-21 16:28:05 +03:00
|
|
|
var _ = require('lodash'),
|
|
|
|
uuid = require('uuid'),
|
|
|
|
moment = require('moment'),
|
|
|
|
Promise = require('bluebird'),
|
|
|
|
ObjectId = require('bson-objectid'),
|
2017-12-14 00:20:02 +03:00
|
|
|
sequence = require('../lib/promise/sequence'),
|
2017-12-12 00:47:46 +03:00
|
|
|
common = require('../lib/common'),
|
2017-11-21 16:28:05 +03:00
|
|
|
htmlToText = require('html-to-text'),
|
|
|
|
ghostBookshelf = require('./base'),
|
|
|
|
config = require('../config'),
|
2018-05-04 16:59:39 +03:00
|
|
|
labs = require('../services/labs'),
|
2017-12-14 17:44:01 +03:00
|
|
|
converters = require('../lib/mobiledoc/converters'),
|
2017-12-11 21:14:05 +03:00
|
|
|
urlService = require('../services/url'),
|
2018-03-27 17:16:15 +03:00
|
|
|
relations = require('./relations'),
|
2014-02-19 17:57:26 +04:00
|
|
|
Post,
|
2014-02-22 01:54:56 +04:00
|
|
|
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
|
|
|
/**
|
|
|
|
* ## NOTE:
|
|
|
|
* We define the defaults on the schema (db) and model level.
|
|
|
|
* When inserting resources, the defaults are available **after** calling `.save`.
|
|
|
|
* But they are available when the model hooks are triggered (e.g. onSaving).
|
|
|
|
* It might be useful to keep them in the model layer for any connected logic.
|
|
|
|
*
|
|
|
|
* e.g. if `model.get('status') === draft; do something;
|
|
|
|
*/
|
|
|
|
defaults: function defaults() {
|
|
|
|
return {
|
|
|
|
uuid: uuid.v4(),
|
|
|
|
status: 'draft'
|
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
relationships: ['tags', 'authors'],
|
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',
|
|
|
|
authors: 'users'
|
|
|
|
},
|
|
|
|
|
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;
|
|
|
|
},
|
|
|
|
|
2017-05-22 11:24:59 +03:00
|
|
|
emitChange: function emitChange(event, options) {
|
2018-04-06 19:19:45 +03:00
|
|
|
let eventToTrigger;
|
2017-05-22 11:24:59 +03:00
|
|
|
|
2015-03-24 23:23:23 +03:00
|
|
|
var resourceType = this.get('page') ? 'page' : 'post';
|
2017-05-22 11:24:59 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
if (options.useUpdatedAttribute) {
|
2015-03-24 23:23:23 +03:00
|
|
|
resourceType = this.updated('page') ? 'page' : 'post';
|
2018-04-06 19:19:45 +03:00
|
|
|
} else if (options.usePreviousAttribute) {
|
|
|
|
resourceType = this.previous('page') ? 'page' : 'post';
|
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) {
|
|
|
|
if (options.method !== 'insert') {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
var 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) {
|
2016-10-14 15:37:01 +03:00
|
|
|
model.statusChanging = model.get('status') !== model.updated('status');
|
|
|
|
model.isPublished = model.get('status') === 'published';
|
|
|
|
model.isScheduled = model.get('status') === 'scheduled';
|
|
|
|
model.wasPublished = model.updated('status') === 'published';
|
|
|
|
model.wasScheduled = model.updated('status') === 'scheduled';
|
|
|
|
model.resourceTypeChanging = model.get('page') !== model.updated('page');
|
|
|
|
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) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unpublished', Object.assign({useUpdatedAttribute: 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) {
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('unscheduled', Object.assign({useUpdatedAttribute: true}, options));
|
2016-10-14 15:37:01 +03:00
|
|
|
}
|
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
model.emitChange('deleted', Object.assign({useUpdatedAttribute: true}, options));
|
|
|
|
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
|
|
|
}
|
|
|
|
},
|
2016-09-19 16:45:36 +03:00
|
|
|
|
2018-04-06 19:19:45 +03:00
|
|
|
onDestroyed: function onDestroyed(model, options) {
|
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
|
|
|
},
|
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
onSaving: function onSaving(model, attr, options) {
|
2016-04-14 14:22:38 +03:00
|
|
|
options = options || {};
|
|
|
|
|
2014-03-24 22:08:06 +04:00
|
|
|
var self = this,
|
2015-10-27 14:15:09 +03:00
|
|
|
title,
|
2016-03-23 16:17:01 +03:00
|
|
|
i,
|
|
|
|
// Variables to make the slug checking more readable
|
2017-11-21 16:28:05 +03:00
|
|
|
newTitle = this.get('title'),
|
|
|
|
newStatus = this.get('status'),
|
2016-05-19 14:49:22 +03:00
|
|
|
olderStatus = this.previous('status'),
|
2018-04-10 23:45:31 +03:00
|
|
|
prevTitle = this.previous('title'),
|
|
|
|
prevSlug = this.previous('slug'),
|
2016-06-02 20:11:54 +03:00
|
|
|
publishedAt = this.get('published_at'),
|
2017-04-06 19:49:59 +03:00
|
|
|
publishedAtHasChanged = this.hasDateChanged('published_at', {beforeWrite: true}),
|
2018-05-04 16:59:39 +03:00
|
|
|
mobiledoc = JSON.parse(this.get('mobiledoc') || null),
|
2018-04-10 23:45:31 +03:00
|
|
|
generatedFields = ['html', 'plaintext'],
|
2017-11-21 16:28:05 +03:00
|
|
|
tagsToSave,
|
|
|
|
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') {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.i18n.t('errors.models.post.isAlreadyPublished', {key: 'status'})
|
2016-10-06 15:27:35 +03:00
|
|
|
}));
|
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) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.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()) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.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')) &&
|
|
|
|
!options.importing
|
|
|
|
) {
|
2017-12-12 00:47:46 +03:00
|
|
|
return Promise.reject(new common.errors.ValidationError({
|
|
|
|
message: common.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
|
|
|
|
2016-10-14 15:37:01 +03:00
|
|
|
ghostBookshelf.Model.prototype.onSaving.call(this, model, attr, options);
|
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
|
|
|
|
generatedFields.forEach((field) => {
|
|
|
|
if (this.hasChanged(field)) {
|
|
|
|
this.set(field, this.previous(field));
|
|
|
|
}
|
|
|
|
});
|
|
|
|
|
2018-05-04 16:59:39 +03:00
|
|
|
// render mobiledoc to HTML. Switch render version if Koenig is enabled
|
|
|
|
// or has been edited with Koenig and is no longer compatible with the
|
|
|
|
// Ghost 1.0 markdown-only renderer
|
|
|
|
// TODO: re-render all content and remove the version toggle for Ghost 2.0
|
2016-09-26 16:23:49 +03:00
|
|
|
if (mobiledoc) {
|
2018-05-04 16:59:39 +03:00
|
|
|
let version = 1;
|
|
|
|
let koenigEnabled = labs.isSet('koenigEditor') === true;
|
|
|
|
|
|
|
|
let mobiledocIsCompatibleWithV1 = function mobiledocIsCompatibleWithV1(doc) {
|
|
|
|
if (doc
|
|
|
|
&& doc.markups.length === 0
|
|
|
|
&& doc.cards.length === 1
|
|
|
|
&& doc.cards[0][0].match(/(?:card-)?markdown/)
|
|
|
|
&& doc.sections.length === 1
|
|
|
|
&& doc.sections[0].length === 2
|
|
|
|
&& doc.sections[0][0] === 10
|
|
|
|
&& doc.sections[0][1] === 0
|
|
|
|
) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
|
|
|
};
|
|
|
|
|
2018-05-15 15:20:40 +03:00
|
|
|
if (koenigEnabled || !mobiledocIsCompatibleWithV1(mobiledoc)) {
|
2018-05-04 16:59:39 +03:00
|
|
|
version = 2;
|
|
|
|
}
|
|
|
|
|
|
|
|
let html = converters.mobiledocConverter.render(mobiledoc, version);
|
|
|
|
this.set('html', html);
|
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')) {
|
2017-04-11 11:55:36 +03:00
|
|
|
this.set('plaintext', htmlToText.fromString(this.get('html'), {
|
|
|
|
wordwrap: 80,
|
|
|
|
ignoreImage: true,
|
|
|
|
hideLinkHrefIfSameAsText: true,
|
|
|
|
preserveNewlines: true,
|
|
|
|
returnDomByDefault: true,
|
|
|
|
uppercaseHeadings: false
|
|
|
|
}));
|
|
|
|
}
|
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) {
|
2017-12-12 00:47:46 +03:00
|
|
|
title = this.get('title') || common.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)) {
|
2014-08-09 23:16:54 +04:00
|
|
|
this.set('published_by', this.contextUser(options));
|
|
|
|
}
|
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) {
|
|
|
|
this.set('published_by', this.previous('published_by'));
|
|
|
|
}
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
2013-06-15 20:11:15 +04: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}
|
|
|
|
).then(function then(prevTitleSlug) {
|
|
|
|
// 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
|
|
|
|
|
|
|
return sequence(ops);
|
2013-06-25 15:43:15 +04:00
|
|
|
},
|
2013-06-01 18:47:41 +04:00
|
|
|
|
2018-03-05 11:10:27 +03:00
|
|
|
emptyStringProperties: function emptyStringProperties() {
|
|
|
|
// CASE: the client might send empty image properties with "" instead of setting them to null.
|
|
|
|
// This can cause GQL to fail. We therefore enforce 'null' for empty image properties.
|
|
|
|
// See https://github.com/TryGhost/GQL/issues/24
|
|
|
|
return ['feature_image', 'og_image', 'twitter_image'];
|
|
|
|
},
|
|
|
|
|
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-04-06 14:32:10 +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
|
|
|
|
* - it needs the following attrs for permalinks
|
|
|
|
* - `slug`: /:slug/
|
|
|
|
* - `published_at`: /:year/:slug
|
|
|
|
* - `author_id`: /:author/:slug, /:primary_author/:slug
|
|
|
|
* - @TODO: with channels, we no longer need these
|
|
|
|
* - because the url service pre-generates urls based on the resources
|
2018-04-25 20:37:39 +03:00
|
|
|
* - you can ask `urlService.getUrlByResourceId(post.id)`
|
2018-04-06 14:32:10 +03:00
|
|
|
* - @TODO: there is currently a bug in here
|
|
|
|
* - you request `fields=title,url`
|
|
|
|
* - you don't use `include=tags`
|
|
|
|
* - your permalink is `/:primary_tag/:slug/`
|
|
|
|
* - we won't fetch the primary tag, ends in `url = /all/my-slug/`
|
|
|
|
* - will be auto fixed when merging channels
|
|
|
|
* - url generator when using `findAll` or `findOne` doesn't work either when using e.g. `columns: title`
|
|
|
|
* - this is because both functions don't make use of `defaultColumnsToFetch`
|
|
|
|
* - will be auto fixed when merging channels
|
|
|
|
*
|
|
|
|
* ### events
|
|
|
|
* - you call `findAll` with `columns: id`
|
|
|
|
* - then you trigger `post.save()`
|
|
|
|
* - bookshelf events (`onSaving`) and model events (`emitChange`) are triggered
|
|
|
|
* - @TODO: we need to disallow this
|
|
|
|
* - you should use `models.Post.edit(..)`
|
|
|
|
* - editing resources denies `columns`
|
|
|
|
* - 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`.
|
|
|
|
*/
|
2016-07-18 23:21:47 +03:00
|
|
|
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) {
|
|
|
|
var defaultFormats = ['html'],
|
|
|
|
formatsToKeep = options.formats || defaultFormats;
|
|
|
|
|
|
|
|
// 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) {
|
|
|
|
var options = Post.filterOptions(unfilteredOptions, 'toJSON'),
|
|
|
|
attrs = ghostBookshelf.Model.prototype.toJSON.call(this, options),
|
2017-07-27 10:55:23 +03:00
|
|
|
oldPostId = attrs.amp,
|
|
|
|
commentId;
|
2014-04-22 05:08:11 +04:00
|
|
|
|
2017-05-30 13:40:39 +03:00
|
|
|
attrs = this.formatsToJSON(attrs, options);
|
|
|
|
|
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
|
|
|
|
|
|
|
if (!options.columns || (options.columns && options.columns.indexOf('url') > -1)) {
|
2017-12-11 21:14:05 +03:00
|
|
|
attrs.url = urlService.utils.urlPathForPost(attrs);
|
2015-07-04 21:27:23 +03: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
|
|
|
|
2017-07-27 10:55:23 +03:00
|
|
|
if (oldPostId) {
|
2017-09-12 18:03:47 +03:00
|
|
|
// CASE: You create a new post on 1.X, you enable disqus. You export your content, you import your content on a different instance.
|
|
|
|
// This time, the importer remembers your old post id in the amp field as ObjectId.
|
|
|
|
if (ObjectId.isValid(oldPostId)) {
|
2017-07-27 10:55:23 +03:00
|
|
|
commentId = oldPostId;
|
2017-09-12 18:03:47 +03:00
|
|
|
} else {
|
|
|
|
oldPostId = Number(oldPostId);
|
|
|
|
|
|
|
|
// CASE: You import an old post id from your LTS blog. Stored in the amp field.
|
|
|
|
if (!isNaN(oldPostId)) {
|
|
|
|
commentId = oldPostId.toString();
|
|
|
|
} else {
|
|
|
|
commentId = attrs.id;
|
|
|
|
}
|
2017-07-27 10:55:23 +03:00
|
|
|
}
|
|
|
|
} else {
|
|
|
|
commentId = attrs.id;
|
|
|
|
}
|
|
|
|
|
|
|
|
// NOTE: we remember the old post id because of disqus
|
|
|
|
attrs.comment_id = commentId;
|
|
|
|
|
2014-04-22 05:08:11 +04:00
|
|
|
return attrs;
|
2015-11-11 20:52:44 +03:00
|
|
|
},
|
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
|
|
|
},
|
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;
|
|
|
|
}
|
|
|
|
|
2018-01-25 19:54:28 +03:00
|
|
|
return options.context && options.context.public ? 'page:false' : 'page:false+status:published';
|
2013-06-25 15:43:15 +04:00
|
|
|
}
|
|
|
|
}, {
|
2017-05-31 17:46:29 +03:00
|
|
|
allowedFormats: ['mobiledoc', 'html', 'plaintext', 'amp'],
|
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'
|
|
|
|
};
|
|
|
|
},
|
|
|
|
|
2016-07-15 13:04:10 +03:00
|
|
|
orderDefaultRaw: function () {
|
|
|
|
return '' +
|
|
|
|
'CASE WHEN posts.status = \'scheduled\' THEN 1 ' +
|
|
|
|
'WHEN posts.status = \'draft\' THEN 2 ' +
|
|
|
|
'ELSE 3 END ASC,' +
|
|
|
|
'posts.published_at DESC,' +
|
|
|
|
'posts.updated_at DESC,' +
|
|
|
|
'posts.id DESC';
|
|
|
|
},
|
|
|
|
|
2015-11-11 22:31:52 +03:00
|
|
|
/**
|
|
|
|
* @deprecated in favour of filter
|
|
|
|
*/
|
|
|
|
processOptions: function processOptions(options) {
|
|
|
|
if (!options.staticPages && !options.status) {
|
|
|
|
return options;
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is the only place that 'options.where' is set now
|
|
|
|
options.where = {statements: []};
|
|
|
|
|
2015-06-17 16:55:39 +03:00
|
|
|
// Step 4: Setup filters (where clauses)
|
2015-11-11 20:52:44 +03:00
|
|
|
if (options.staticPages && options.staticPages !== 'all') {
|
2015-06-17 16:55:39 +03:00
|
|
|
// convert string true/false to boolean
|
|
|
|
if (!_.isBoolean(options.staticPages)) {
|
2016-06-11 21:23:27 +03:00
|
|
|
options.staticPages = _.includes(['true', '1'], options.staticPages);
|
2015-06-17 16:55:39 +03:00
|
|
|
}
|
2015-11-11 22:31:52 +03:00
|
|
|
options.where.statements.push({prop: 'page', op: '=', value: options.staticPages});
|
|
|
|
delete options.staticPages;
|
|
|
|
} else if (options.staticPages === 'all') {
|
|
|
|
options.where.statements.push({prop: 'page', op: 'IN', value: [true, false]});
|
|
|
|
delete options.staticPages;
|
2015-06-17 16:55:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
// Unless `all` is passed as an option, filter on
|
|
|
|
// the status provided.
|
2015-11-11 20:52:44 +03:00
|
|
|
if (options.status && options.status !== 'all') {
|
2015-06-17 16:55:39 +03:00
|
|
|
// make sure that status is valid
|
2016-05-19 14:49:22 +03:00
|
|
|
options.status = _.includes(['published', 'draft', 'scheduled'], options.status) ? options.status : 'published';
|
2015-11-11 22:31:52 +03:00
|
|
|
options.where.statements.push({prop: 'status', op: '=', value: options.status});
|
|
|
|
delete options.status;
|
2015-11-11 20:52:44 +03:00
|
|
|
} else if (options.status === 'all') {
|
2016-05-19 14:49:22 +03:00
|
|
|
options.where.statements.push({prop: 'status', op: 'IN', value: ['published', 'draft', 'scheduled']});
|
2015-11-11 22:31:52 +03:00
|
|
|
delete options.status;
|
2015-06-17 16:55:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return options;
|
|
|
|
},
|
2013-06-01 18:47:41 +04: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) {
|
2014-05-06 05:45:08 +04:00
|
|
|
var options = ghostBookshelf.Model.permittedOptions(),
|
|
|
|
|
|
|
|
// whitelists for the `options` hash argument on methods, by method name.
|
|
|
|
// these are the only options that can be passed to Bookshelf / Knex.
|
|
|
|
validOptions = {
|
2017-11-14 02:18:59 +03:00
|
|
|
findOne: ['columns', 'importing', 'withRelated', 'require'],
|
2015-10-22 15:49:15 +03:00
|
|
|
findPage: ['page', 'limit', 'columns', 'filter', 'order', 'status', 'staticPages'],
|
2017-11-14 02:18:59 +03:00
|
|
|
findAll: ['columns', 'filter']
|
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.
|
|
|
|
*/
|
|
|
|
defaultRelations: function defaultRelations(methodName, options) {
|
|
|
|
if (['edit', 'add'].indexOf(methodName) !== -1) {
|
|
|
|
options.withRelated = _.union(this.prototype.relationships, options.withRelated || []);
|
|
|
|
}
|
|
|
|
|
|
|
|
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) {
|
2017-04-19 11:59:09 +03:00
|
|
|
var filteredData = ghostBookshelf.Model.filterData.apply(this, arguments),
|
2017-11-21 16:28:05 +03:00
|
|
|
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)
|
|
|
|
*/
|
2015-06-14 18:58:49 +03:00
|
|
|
findOne: function findOne(data, options) {
|
2015-06-25 21:56:27 +03:00
|
|
|
data = _.defaults(data || {}, {
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
status: 'published'
|
2015-06-25 21:56:27 +03:00
|
|
|
});
|
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
|
|
|
* @extends ghostBookshelf.Model.edit to handle returning the full object and manage _updatedAttributes
|
|
|
|
* **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
|
|
|
|
found._updatedAttributes = post._updatedAttributes;
|
|
|
|
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.
|
|
|
|
permissible: function permissible(postModel, action, context, unsafeAttrs, loadedPermissions, hasUserPermission, hasAppPermission, result) {
|
|
|
|
let isContributor, isEdit, isAdd, isDestroy;
|
2018-02-21 18:59:48 +03:00
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
result = result || {};
|
Consistency in model method naming
- The API has the BREAD naming for methods
- The model now has findAll, findOne, findPage (where needed), edit, add and destroy, meaning it is similar but with a bit more flexibility
- browse, read, update, create, and delete, which were effectively just aliases, have all been removed.
- added jsDoc for the model methods
2014-05-05 19:18:38 +04:00
|
|
|
|
2017-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'});
|
|
|
|
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();
|
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
|
|
|
|
if (result.excludedAttrs) {
|
|
|
|
result.excludedAttrs.push('tags');
|
|
|
|
} else {
|
|
|
|
result.excludedAttrs = ['tags'];
|
|
|
|
}
|
2014-05-14 05:49:07 +04:00
|
|
|
}
|
|
|
|
|
|
|
|
if (hasUserPermission && hasAppPermission) {
|
2018-02-07 12:46:22 +03:00
|
|
|
return Promise.resolve(result);
|
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
|
|
|
}
|
|
|
|
|
2018-03-27 17:16:15 +03:00
|
|
|
return Promise.reject(new common.errors.NoPermissionError({
|
|
|
|
message: common.i18n.t('errors.models.post.notEnoughPermission')
|
|
|
|
}));
|
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
|
|
|
};
|