refs https://github.com/TryGhost/Team/issues/849
As part of work for segmented post access with multiple products, the custom filter for post access is stored in `visibility` field on posts but passed with `visibility_filter` property on API. This change -
- updates input serializer of posts to transform `visibility` and `visibility_filter` properties correctly
- updates output serializer for canary to transform and send `visibility_filter` attribute with filter value
- updates output serializer for v3 to ignore any custom filter on visibility and return `paid` instead as v3 didn't have a concept of custom filter
refs https://github.com/TryGhost/Team/issues/849
Custom post visibility (behind alpha flag) is added to the API using new `visibility_filter` attribute that stores the custom filter. This change -
- updates validator for visibility to check new `visibility_filter` property
- cleans usage of i18n in favor of tpl
refs https://github.com/TryGhost/Team/issues/727
- The version was forgotten to get a bump durin g 4.0 release. The API version used by update check should be the same as internal default.
- Because the current internal default is mistakenly set to v3 API it's still not optimal but will need a holistic solution in the future
no refs
- adds `price` data on subscription from related `stripe_price` on updating a member via frontend
- removes inconsistency between `GET` and `PUT` data for logged in member on a site
refs https://github.com/TryGhost/Team/issues/828
- Previous method had a bug where it didn't take into account cases when onlya single card with a segment filter has been used leaving the members not covered by that filter without an email
refs https://github.com/TryGhost/Team/issues/828
- Before sending out batches with members we need to partition all members based on the segment they belong to. Special segment "unsegmented" is used in case none of the segments used in the emal cards cover part of the members set (for example only free members card used when emailing all members)
refs https://github.com/TryGhost/Team/issues/839
It's now possible to set alt and caption for post feature images using `feature_image_alt` and `feature_image_caption` fields on a post resource.
- `feature_image_alt` - plain text, limited to 191 chars (alt text is not recommended to be longer than 125 chars, screen readers may cut the description off at that point)
- `feature_image_caption` - basic HTML, limited to 65535 chars
Alt and caption will be automatically used inside of newsletter content, for your website content make sure your theme is updated to use the v4 API and make use of the new properties.
---
- removed `featureImageMeta` labs flag
- This is part of the quest to separate the frontend and server & get rid of all the places where there are cross-requires
- At the moment the settings cache is one big shared cache used by the frontend and server liberally
- This change doesn't really solve the fundamental problems, as we still depend on events, and requires from inside frontend
- However it allows us to control the misuse slightly better by getting rid of restricted requires and turning on that eslint ruleset
- requiring lib/common/events makes the settings cache tightly coupled to the server
- moving this up to settings index means the cache itself can be moved to a shared component/moved out of Ghost
- the index then becomes the settings manager
- questionable whether the event listeners & updater part of this shouldn't be part of a manager, independent of the actual cache 🤔
refs https://github.com/TryGhost/Team/issues/828
- We need a way to recreate a filter that was used to create an email content for specific email_recipient. By saving member_segment value for each email_batch we can traverse back to the filter that was applied during email creation.
- shutdown removed listeners, which should really be done before adding them anyway!
- reset sets the cache back to an empty object, which was already done by init
- merge these into one reset function that fully resets the cache
- all instances of shutdown were called before an init call, and now called during init, therefore these can be removed
- acceptance utils had an instance of calling shutdown and reset together as part of stopping Ghost, reworked that to be clearer
refs https://github.com/TryGhost/Team/issues/828
- When sending email batches out they need to be created without mixing different member segments. This allows for easier reasoning about what data has been sent out to each specific email recipient
- Modified email batches to chunk based on segments defined in the HTML content of the post
refs https://github.com/TryGhost/Team/issues/828
- When detecting email segments and later creating a member filter out of this data we only care about unique segments otherwise we'd be creating multiple batches with the same segment filter
refs https://github.com/TryGhost/Team/issues/828
- This is experimental segment extraction logic, more to follow. Alllows to extract arrays of email segments used in the email's HTML content
- The main goal here is getting this settings related code out of the routing service as it really doesn't belong there
- This settings file is used purely by the API to get and set files - its not really anything to do with actual routing
- This file calls out to the bridge to do a reload, which helps decouple slightly
- More refactoring is needed to get rid of the urlService dependency
- Note this file is really similar to the redirects one, it would be good to merge them
- At the moment the bootstrap.start method asks the settings service for its settings
- This couples the routing and settings services together - when maybe we want to use a different method to generate settings
- By passing the settings to the routing service at the right time, we open up possibilities for refactoring
- Allows for slight decoupling of API and frontend with route settings being updated
- Activate theme now calls the same codepath to reload the frontend
- Yet another step on the path to make it possible to init/reload/run the frontend independently from the server
refs https://github.com/TryGhost/Team/issues/806
This relation sets up the ability to both read and write relations via
the Product model, allowing us to expose benefits via the Admin Product
API.
refs https://github.com/TryGhost/Team/issues/806
This is the model to represent the Benefit resource stored in the
`benefits` table. The `onSaving` method has been copied from the Tag
model and ensures that we have a unique slug.
fixes https://github.com/TryGhost/Team/issues/834
- see referenced issue for context
- there are times when `parentPort` can be null and the job crashes
because `parentPort.postMessage` won't work
- this commit adds guards around `parentPort`, or moves code inside
existing guards, to protect against this
refs https://github.com/TryGhost/Ghost/pull/13091
- When the job is run under Node v14 with SQLite DB the parentPort is `null` in some of the environments. The guarding code protects from the job crashing in such situation.
- The most probable cause is running btrheds with `BTHREADS_BACKEND = 'child_process';` configuration for SQLite. Should be fixed once https://github.com/mapbox/node-sqlite3/issues/1386 is properly resolved
- Makes the logic for determining the admin and frontend vhost args independent and easier to test
- Moved the tests to specifically test the vhost utils & removed proxyquire as a dependency
- We want to breakdown the current parent app into the existing core/app.js and boot code, allowing us to decouple the backend and frontend further
- This is all part of the refactoring to separate server and frontend completely
fixes https://github.com/TryGhost/Team/issues/818
- validation on query parameters should be wrapped in `options` within
`validation`
- this is missing from the theme install API endpoint so we don't force
the parameters to be passed in
- Ghost throws a 500 if `ref` is not supplied because following code
assumes we've checked the existence
- this commit wraps the two query parameter validation statements in
an `options` object to ensure they exist - Ghost returns a 422 if
missing
refs d9ddc2db6a
refs https://github.com/TryGhost/Team/issues/754
- The tests were written with falsy assumptions and validation added in refed commit have uncovered it!
- A secondary issue touched here is additional JSON object serialization that is used in the "input serializer" -d9ddc2db6a/core/server/api/v2/utils/serializers/input/settings.js (L107-L110)
- The additional stringification should not be there at all. It covers for a mistaken internal use of Settings API where raw objects are passed around instead of serialized JSON Objects (see commets left with this changeset for details)
refs https://github.com/TryGhost/Team/issues/754
refs a7dec233ba
- Additional validation protects from problems like the ones in refed commit from even getting through to the database.
- At the moment only used notificatons and couple more settings to ensure they are arrays when passed into the API. This is to avoid making big change in settings straight away - this is a problematic area which needs cautious approach.
- Ideally in the future the list of settings to check the "array" type (and other types) should be automatically generated based on the default-settings.json (or whatever way we define settings in the db a that moment)
- There's an ugly code-tripplication going on in this change. This is a separate topic that will be addressed once we work on API cleanup.
refs https://github.com/TryGhost/Team/issues/804
The associative table is used to implement the many-to-many relationship
between Products and Benefits. The `sort_order` column is needed because
a product's benefits should be orderable by an admin.
refs https://github.com/TryGhost/Team/issues/804
Benefits are tag-like resources which will be associated with Products.
The first iteration just requires a name for the benefit, which will be
stored as plaintext.
refs 188de00489
- this fix was incorrect - the function should have been on the
prototype but I'd moved it over incorrectly into the static class functions
- this commit moves `defaultColumnsToFetch` to the prototype functions
and reverts the referenced commit back to `this.prototype` as expected
- this wasn't including the custom columns from the `post` model, which
was causing tests to fail
- pro tip: run tests!
