Ghost/core/server/models/plugins/index.js

module.exports = {
    eagerLoad: require('./eager-load'),
    filter: require('./filter'),
    order: require('./order'),
    customQuery: require('./custom-query'),
    search: require('./search'),
    includeCount: require('./include-count'),
    pagination: require('./pagination'),
    collision: require('./collision'),
    transactionEvents: require('./transaction-events'),
    hasPosts: require('./has-posts')
};
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`module.exports = {`
Added support for ordering Post API resources by fields coming form posts_meta table (#12226) refs #11729 - When ordering is done by fields from a relation (like post's `meta_title` that comes form `posts_meta` table), Bookshelf does not include those relations in the original query which caused errors. To support this usecase added a mechanism to detect fields from a relation and load those relations into query. - Extended ordering to include table name in ordered field name. The information about the table name is needed to avoid using `tableName` within pagination plugin and gives path to having other than original table ordering fields (e.g. order by posts_meta table fields) - Added test case to check ordering on posts_meta fields - Added support for "eager loading" relations. Allows to extend query builder object with joins to related tables, which could be used in ordering (possibly in filtering later). Bookshelf does not support ordering/filtering by proprieties coming from relations, that's why this kind of plugin and query expansion is needed - Added note about lack of support for child relations with same property names. 2020-09-24 04:32:40 +03:00			`eagerLoad: require('./eager-load'),`
Filter plugin with enforce/default logic refs #5614, #5943 - adds a new 'filter' bookshelf plugin which extends the model - the filter plugin provides handling for merging/combining various filters (enforced, defaults and custom/user-provided) - the filter plugin also handles the calls to gql - post processing is also moved to the plugin, to be further refactored/removed in future - adds tests showing how filter could be abused prior to this commit 2015-11-11 20:52:44 +03:00			`filter: require('./filter'),`
Extracted ordering into separate bookshelf plugin refs #11729 - Having a plugin allows to reason about ordering better and gives way to further extraction away form the core. - Just like with filtering, ordering falls into similar category of having effect on knex'es query builder object extension through additional statements - ORDER BY in this case. - Because there were bugs associated with use of permittedAttributes inside of `parseOrderOption` method, introduced separate `orderAttributes` function which returns only those fields which are orderable (https://github.com/TryGhost/Ghost/issues/11729#issuecomment-685740836) 2020-09-08 07:15:47 +03:00			`order: require('./order'),`
Added `?paid` query parameter to Admin API members browse endpoint (#11892) no issue - NQL does not support the relationship setup that members->stripe customer<->stripe subscriptions uses so it wasn't possible to use the `filter` param to query against having an active subscription - adds `customQuery` bookshelf plugin that allows customisation of SQL query used in `findPage` method by individual models - use `customQuery` in Member model to set up joins and conditionals to select free/paid members when `options.paid` is present - allow `?paid` param through API and permitted options for member model 2020-06-12 14:12:10 +03:00			`customQuery: require('./custom-query'),`
✨ Added `?search=` param to Admin API members endpoint (#11854) no issue - adds `search` bookshelf plugin that calls out to an optional `searchQuery()` method on individual models to apply model-specific SQL conditions to queries - updated the base model's `findPage()` method to use the search plugin within `findPage` calls - added a `searchQuery` method to the `member` model that performs a basic `LIKE %query%` for both `name` and `email` columns - allowed the `?search=` parameter to pass through in the `options` object for member browse requests 2020-05-28 12:14:02 +03:00			`search: require('./search'),`
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`includeCount: require('./include-count'),`
✨ post update collision detection (#8328) (#8362) closes #5599 If two users edit the same post, it can happen that they override each others content or post settings. With this change this won't happen anymore. ✨ Update collision for posts - add a new bookshelf plugin to detect these changes - use the `changed` object of bookshelf -> we don't have to create our own diff - compare client and server updated_at field - run editing posts in a transaction (see comments in code base) 🙀 update collision for tags - `updateTags` for adding posts on `onCreated` - happens after the post was inserted --> it's "okay" to attach the tags afterwards on insert --> there is no need to add collision for inserting data --> it's very hard to move the updateTags call to `onCreating`, because the `updateTags` function queries the database to look up the affected post - `updateTags` while editing posts on `onSaving` - all operations run in a transactions and are rolled back if something get's rejected - Post model edit: if we push a transaction from outside, take this one ✨ introduce options.forUpdate - if two queries happening in a transaction we have to signalise knex/mysql that we select for an update - otherwise the following case happens: >> you fetch posts for an update >> a user requests comes in and updates the post (e.g. sets title to "X") >> you update the fetched posts, title would get overriden to the old one use options.forUpdate and protect internal post updates: model listeners - use a transaction for listener updates - signalise forUpdate - write a complex test use options.forUpdate and protect internal post updates: scheduling - publish endpoint runs in a transaction - add complex test - @TODO: right now scheduling api uses posts api, therefor we had to extend the options for api's >> allowed to pass transactions through it >> but these are only allowed if defined from outside {opts: [...]} >> so i think this is fine and not dirty >> will wait for opinions >> alternatively we have to re-write the scheduling endpoint to use the models directly 2017-04-19 16:53:23 +03:00			`pagination: require('./pagination'),`
Fixed model events and transactions (#9524) no issue - if multiple queries run in a transaction, the model events are triggered before the txn finished - if the txn rolls back, the events are anyway emitted - the events are triggered too early - solution: - `emitChange` needs to detect that a transaction is happening - it listens on a txn event to determine if events should be triggered 2018-04-06 19:19:45 +03:00			`collision: require('./collision'),`
Added plugin based author and public tag models in API v2 (#10284) refs #10124 - Author model returns only users that have published non-page posts - Added a public controller for tags (should be extracted to separate Content API controller https://github.com/TryGhost/Ghost/issues/10106) - Made resource configuration dynamic based on current theme engine - This needs a follow-up PR with fixes to the problems described in the PR 2019-01-03 22:30:35 +03:00			`transactionEvents: require('./transaction-events'),`
			`hasPosts: require('./has-posts')`
Move bookshelf plugins into own folder 2015-11-11 21:24:24 +03:00			`};`