Rather than calling itself with the newly created transaction, it would call
the "parent" method, which meant that two events were dispatched. TBH I think
we can get rid of the check for a transaction here, and so the parent method
too, but not 100% sure.
Our service layer should not expose the Entities, it should return the DTOs.
This is to allow us to make internal refactors without having to modify the
entire stack.
no issue
`PostsService` and `CollectionsService` were missing some passthroughs and had differing naming for a transaction instance on the `options` object which meant SQLite would hang if the Lexical renderer called out to `PostsService.browsePosts`
- added passthrough of `transacting` to the Lexical renderer ready for implementation of the collection-fetching function
- added rename of `options.transacting` to `options.transaction` and passthrough from `PostsService` to `CollectionsService` (passthrough from collections repository to bookshelf and required `transaction->transacting` was already in place)
This will allow us to browse posts based on their collection which will
be used for rendering the collections card. As with the Collections API
we're not opening up the write endpoints yet.
refs https://ghost.slack.com/archives/C02G9E68C/p1692816097875899
- With introduction of extra e2e test coverage for Collections some tests started to fail at random. The root issue here was the transaction processing collections was started before the original bulk action (bulk edit, bulk publish/unpublish, etc.) was fully committed. The full transaction commit happens with the bulkAction method return inside of `if (!options.transacting) {` block.
refs https://github.com/TryGhost/Arch/issues/77
- During initial development we have missed to support collections update when tags are added to posts in bulk. It's especially valid usecase since we can define automatic collection with a filter containing not yet existing tags.
refs https://github.com/TryGhost/Arch/issues/16
- Allows to subscribe to bulk unpublish/featured/unfeatured DomainEvents elsewhere in the system, for example, Collections.
refs https://github.com/TryGhost/Arch/issues/16
- When the bulk destroy is done on posts Collections need to know about the update and remove the stored posts from collections.
closes https://github.com/TryGhost/Arch/issues/58
- Following assumptions were broken:
- Posts Admin API should include posts of all statuses when filtering by collection
- Posts Content API should not include any unpublished posts
- Updated the "status" filter which fixes the problem. We still disallow any custom filters to be applied on top of collections filter.
closes https://github.com/TryGhost/Product/issues/3557
- bumped `@tryghost/admin-api-schema` to allow passthrough of the new property in API requests
- updated output mapper to ensure property always returns a boolean rather than `null` in the case where `posts_meta` doesn't exist for a page
- updated `PostsService.copyPost()` to include the new property when copying
- updated `checkResponse` test util and snapshots to expect `hide_title_and_feature_image` property in page API responses
- fixed pages e2e test so it doesn't inadvertently modify the match object breaking later tests
closes https://github.com/TryGhost/Team/issues/3521
When duplicating a newsletter (email only post) some of the fields
relating to the newsletter (i.e `newsletter_id`) were being erroneously
copied over. Upon publishing this made the post appear as if it was an
email only post that had been sent to subscribers when it actually had
not
closes https://github.com/TryGhost/Team/issues/3423
- For convenience we need a way to fetch posts that belong to a certain collection. This change adds support for `collection` query parameter: `/?collection=` which can be either an id or slug of the collections we are trying to fetch.
- When posts are fetched by collection we ignore any filters passed along in query parameters as collection is a "filter" by it's very nature.
We've got some fairly simple diffing logic here to update the collections which
a post is in, the bulk of the changes here are to support the return of a DTO
rather than Bookshelf Model. This also helps improve the architecture because
we are step closer to removing infrastructure concerns (HTTP Response Headers)
from the business logic layer.
For now there is a crappy EventString which can be passed back to the
controller which can then handle any HTTP related concerns, although long term
these should be actual events like PostPublished or PostUpdated.
refs: https://github.com/TryGhost/Team/issues/3139https://github.com/TryGhost/Team/issues/3140
- Added duplicate post functionality to post list context menu
- Currently only a single post can be duplicated at a time
- Currently only enabled via the `Making it rain` flag
- Added admin API endpoint to copy a post - `POST ghost/api/admin/posts/<post_id>/copy/`
- Added admin API endpoint to copy a page - `POST ghost/api/admin/pages/<page_id>/copy/`
no issue
The post/page bulk actions weren't logged in the history log / actions
table.
This change adds support for logging bulk actions.
- New `addActions` static method on models. It creates an action log in
the database for multiple models at once. If only one model was edited,
deleted or added, it will fallback to `addAction`
- `addAction` can also be called statically now
- `actionName` option is now supported when using `addActions`,
`addAction`, and as a result also in all bulk manipulation methods, and
CRUD methods. This allows you to replace the default '5 posts edited'
into something more specific like '5 posts featured'
- Fixed support for null resource_id in the parse-history-event helper
- Removed the default 'published' status requirement when using
Post.findOne for internal queries.
fixes https://github.com/TryGhost/Team/issues/2924
This change adds a new bulk edit action for posts to update their
visibility. It also implements a modal to change the post access level
for multiple posts at once using this new API.
It also fixes a pattern that was used when modifying the Ember models in
memory. They previously were marked as dirty, this is fixed now. So when
going to the editor after modifying posts, you won't get a confirmation
dialog any longer.
fixes https://github.com/TryGhost/Team/issues/2919
This pull request implements a new feature that allows bulk editing of
posts by a filter. It adds a new `bulkEdit` endpoint to the posts API
and new `PostsService` methods to handle the bulk actions.
The posts list component is duplicated, so we can keep working in a
copied version without affecting the old version without a flag. It
temporarily adds a star icon to indicate featured posts in the posts
list.
