refs https://github.com/TryGhost/Team/issues/793
New settings added for newsletter customisation options:
- `newsletter_header_image` - `null/"$url"`
- `newsletter_show_header_icon` - `"true/false"`
- `newsletter_show_header_title` - `"true/false"`
- `newsletter_title_alignment` - `"center/left"`
- `newsletter_title_font_category` - `"serif/sans_serif"`
- `newsletter_show_feature_image` - `"true/false"`
`newsletter_show_header` has been dropped because the same functionality can be achieved by setting both `newsletter_show_header_icon` and `newsletter_show_header_title` to `false`
---
- migration to convert and delete `newsletter_show_header` setting
- removed `newsletter_show_header` from default settings to ensure it doesn't get re-created
- replaced main labs template and template settings generation with the labs template
- deleted labs template
refs https://github.com/TryGhost/Team/issues/768
- `portal_products` stores list of products available in Portal
- adds new `portal_products` setting to default settings
- adds migration to populate `portal_products` with current product so its available by default
- update tests
- Part of the effort to split Ghost down into smaller, decoupled pieces
- Moved out our internal validator tooling to a separate library
- Replaced all usage of our own tooling and validatorjs directly with @tryghost/validator
- Removed the validatorjs dependency and removed the renovate pin
- This gives us a consistant, smaller, clearer public API for validations
- It will eventually be used on Ghost Admin too
- This way we can start getting up to date with validator whilst not increasing build size
refs https://github.com/TryGhost/Team/issues/770
We want post feature image functionality to better match what's available inside the editor, to do that we'll need somewhere to store alt and caption meta data. `posts_meta` chosen because even though we want to make this generic for other tables in the future those tables also have a `feature_image` (or closely related) field.
- updated schema with new columns
- added migration to create columns
- cleaned new columns from API output
- not output on v2/v3
- conditionally output on v4/canary output based on labs flag
- bumped `@tryghost/admin-api-schema` to allow new columns through in canary API requests
- silently clean properties from input when labs flag is disabled
- updated acceptance tests so they fail if `admin-api-schema` is not letting the new fields through
no issue
Shows impact of new code behind labs flags through the existing acceptance/regression tests. Allows for existing tests to be updated to match new behaviour rather than requiring separate tests where individual flags are enabled. Should result in minimal test updating once code reaches GA.
- adds a forced `'labs:enabled'` fixture op that edits the `labs` setting to enable all flags then restarts the settings service to pick up the new setting
- modifies labs service to not remove ALPHA_FEATURE labs settings when running in a testing environment
refs https://github.com/TryGhost/Team/issues/757
- The "type" value in settings is meant to be representing the data type stored in the "value" field. It was an overlooked bug in v4 API adding a mapper to group->type
refs https://github.com/TryGhost/Team/issues/757
- Groups are meant to represent the group to which the settings key belongs and have the same value as stored in the DB. This was an evolution of v2/v3 API's "type"
- Having a fixed value for groups in a test will make it easier to track the "type" change that is about to land
refs https://github.com/TryGhost/Team/issues/757
- There is no usecase for editing "labs" settings outside of canary/v4 API versions. Removing support for older versions makes the supported API surface smaller (easy maintenance).
refs https://github.com/TryGhost/Team/issues/757
- To safeguard from mise of a very permissing "object" value of the "labs" setting this change introduces an "allowlist" approach to filtering unrecognized labs flags
- Should allow maintainers to have a clear view of which labs flags are currently in use and manage them accordingly
* 🐛 Fixed saving Members with Complimentary plans
refs https://github.com/TryGhost/Team/issues/758
Since 4.6 The Admin is using the comped flag again, rather than creating
subscriptions for zero-amount prices directly. With the `comped` flag
removed, the default state was for it to be falsy in the Admin, and when
saved would trigger the legacy comped flow, cancelling the subscription.
This reverts commit 57a176ff3d.
refs https://github.com/TryGhost/Team/issues/728
- This is the end of the refactor for update check tests. There are no dependencies for Ghost server process to run this test suite!
- Next steps will be extracting the service to an outside module
refs https://github.com/TryGhost/Team/issues/728
- Rewire is usually a sign of massive module that is impossible to unit test without mocking big parts of that module. With a refactored UpdateCheckService and a brand new test coverage there is no need to use rewire and leave the "smell"
refs https://github.com/TryGhost/Team/issues/728
- This is a continuation of the test coverage for the UpdateCheckService.
- Covers scpecial cases of notification processing within Update Check
- The refactor inside the update check service was a convenience to get rid or the Bluebird dependency completely. Also, some minor preventative code added to avoid errors from referencing undefined objects
refs https://github.com/TryGhost/Team/issues/728
- This is a continuation of the test coverage for the UpdateCheckService.
- Covers a basic check for what kind of data is sent from the service to external analytics
refs https://github.com/TryGhost/Team/issues/728
- This approach is moving away from stubbing and "rewiring" massive internal modules and instead only stubs needed dependencies for the UpdateCheckService class
- Also eliminates the need to depend on the database fixtures which should speed up test execution and move it to proper "unit test" class when the test rewrite is complete
- starting and stopping Ghost is part of our rather unloved acceptance test framework
- moving them into their own file to make the different pieces clearer and also to start to make improvements
- first improvement had to happen as an aside - exposing the existingData property via a function and making the API clearer
- this was a weird thing set on module.exports, very hidden and hard to follow
- Note: stopGhost is only used once in the regression/modles/model_posts_spec.js file to make the test run fast enough...
- These tests are effectively "DB integration" tests e.g. non-unit tests because they do use the DB, they need their own framework
- These tests protect some advanced, yet important behaviour around URLs
- Moved them out of regression tests into acceptance, as we're slowly trying to clean up regression tests :)
- Checking for differences in behaviour when urls are configured with or without slashes should fall to unit testing
- Generally testing that a correctly configured subdirectory site does what's expected is an acceptance test
- Ghost's 301 to trailing slash behaviour is also well tested, and doesn't need extensive acceptance tests when using a subdir
- Instead, test that the non-subdirectory equivalent route is 404ing as expected, to check that routes are ONLY mounted on the subdir, as well as mounted at all
refs https://github.com/TryGhost/Team/issues/726
- When UpdateCheck service sends a notification with "type: 'alert'" an email goes out to admin users with the "message" content of the notification.
- This functionality is aimed to handling critical messages like urgent instance updates
- Next step will be getting as much of the update check code extracted into a "service" and then moved out of Ghost's codebase
refs: f1be3418d9
- Since I refactored the boot process & subsequently the test tools, I have been hitting an issue where subdirectory tests don't work if the app has already been started without a subdirectory
- Turns out it's due to the rootApp getting cached, and not replaced no matter what you do, even though if you debug it _looks_ like it's been replaced
- This makes sense as the rootApp is in a separate file and therefore subject to the node module cache and we're using const everywhere
- Therefore, I have added a single line to the test utils to destroy this cache for this file, and the tests now work perfectly
- Next: refactor the test utilities some more to make all this much, much more straightforward and easy to understand
no-issue
These tests were skipped out due to adding with the subscriptions
relation not working. However this functionality is redundant, as it is
not used anywhere. The tests have been updated to test that we can read
the subscriptions relation correctly.
no-issue
We no longer want to include skipped tests in the codebase. These tests
were added as placeholders until a point at which we were able to mock
Stripe.
We haven't got time during cleanup to mock Stripe so removing these
tests for now.
refs https://github.com/TryGhost/Team/issues/694
- Unskipping the test does not seem to be causing a failure any longer. Removed the skip as it would be causing linting errors as we tighten up the `.skip` rules
refs https://github.com/TryGhost/Team/issues/694
- The previous `.then` chaining was outdated, while in this part of code did a tiny cleanup which should improve future maintenance slightly
refs https://github.com/TryGhost/Team/issues/694
- The previous `.then` chaining was outdated and was causing 2x ghost instance initialization per test suite
- With a refactor there's only one intance initialization per suite (saves running time!) and we use more readable async/await syntax, which should make things more maintainable
refs https://github.com/TryGhost/Team/issues/694
- The tests were skipped and were throwing an eslint warning, which soon will become an error.
- They were skipped initially as they used an outdated authorization mechanism. With migration to token based auth the tests are green again
no issue
- The test was skipped, which should not have been commited into the trunk in the first place. The checks were reworked to reflect the reality - the endpoint ignores the "group" qurey parameter
no-issue
This protects our tests against changes to the database schema, which
helps us decouple the API from the database, and make tests less
brittle. It also forces us to manually update the tests if we do make a
change to the API!
closes https://github.com/TryGhost/Team/issues/699
With custom products, saving a member with subscriptions on member detail page in Admin throws errors on console, though the save is successful. This breaks the Admin as user needs to refresh the screen again to get rid of error. This change -
- updates the response on member save to return `price` object in subscription
- updates tests
no refs
Since backend now allows multiple prices but we want the prices to be currently limited to monthly/yearly on UI, we need new settings to store the current monthly/yearly price by the site owner. These settings determine the active prices shown in Admin / Portal for the site till we allow all custom products/prices again.
refs https://github.com/TryGhost/Team/issues/687
- The frontmatter field has leaked into the API layer unintentionally when it was introduced into the DB schema during 4.0 release.
- The fix add the field to "trim" list in all API. A proper validation and handling will be add per API as usecase for the field becomes clear
refs https://github.com/TryGhost/Team/issues/687
- The approach of generating validation properties using `/server/data/schema` package's tables object is prone to leaking unwanted database fields into API responses
- This refactor takes a tiny step into direction of relying on "allowlist" approach for properties in the API response resources.
- Apart from solving the described property leak problem it also moves toward decoupling tests from `/core/server` dependencies!
refs https://github.com/TryGhost/Team/issues/581
closes https://github.com/TryGhost/Team/issues/582
Emails can now be sent to members with specific associated labels or products by specifying an NQL string. We want to bring the same members segment feature to content by allowing `visibility` to be an NQL filter string on top of the `public/members/paid` special-case strings.
As an example it's possible to set `posts.visibility` to `label:vip` to make a post available only to those members with the `vip` label.
- removed enum validations for `visibility` so it now accepts any string or `null`
- bumped `@tryghost/admin-api-schema` for API-level validation changes
- added nql validation to API input validators by running the visibility query against the members model
- added transform of NQL to special-case visibility values when saving post model
- ensures there's a single way of representing "members" and "paid" where NQL gives multiple ways of representing the same segment
- useful for keeping theme-level checks such as `{{#has visibility="paid"}}` working as expected
- updated content-gating to parse nql from post's visibility and use it to query the currently logged in member to see if there's a match
- bumped @tryghost/members-api to include label and product data when loading member
refs https://github.com/TryGhost/Team/issues/637
The "free" price - when Members signup without using Stripe, should have
a name and description, so that it can be displayed in Portal in a
similar way to paid price's. As there is only ever one, and it is not a
fully fledged price, a setting makes more sense than a dedicated db
table.
refs https://github.com/TryGhost/Team/issues/581
refs https://github.com/TryGhost/Team/issues/582
When publishing a post via the API it was possible to send it using `?email_recipient_filter=all/free/paid` which allowed you to send to members only based on their payment status which is quite limiting for some sites.
This PR updates the `?email_recipient_filter` query param to support Ghost's `?filter` param syntax which enables more specific recipient lists, eg:
`?email_recipient_filter=status:free` = free members only
`?email_recipient_filter=status:paid` = paid members only
`?email_recipient_filter=label:vip` = members that have the `vip` label attached
`?email_recipient_filter=status:paid,label:vip` = paid members and members that have the `vip` label attached
The older `free/paid` values are still supported by the API for backwards compatibility.
- updates `Post` and `Email` models to transform legacy `free` and `paid` values to their NQL equivalents on read/write
- lets us not worry about supporting legacy values elsewhere in the code
- cleanup migration to transform all rows slated for 5.0
- removes schema and API `isIn` validations for recipient filters so allow free-form filters
- updates posts API input serializers to transform `free` and `paid` values in the `?email_recipient_filter` param to their NQL equivalents for backwards compatibility
- updates Post API controllers `edit` methods to run a query using the supplied filter to verify that it's valid
- updates `mega` service to use the filter directly when selecting recipients
refs https://github.com/TryGhost/Team/issues/581
Editors are allowed to restrict post visibility and send emails to particular member segments, they need to be able to read labels so that they can select them in a member segment.
refs https://github.com/TryGhost/Team/issues/496
We want to give more control over the default selection of email recipients when publishing a post, to do that we need somewhere to store those settings. These settings are site-wide and intended for use by admins to control the default editor behaviour for all staff users. They _do not_ control API behaviour, if you want to send email when publishing via the API it's still necessary to explicitly opt in to that using the `?email_recipients_filter=` query param.
- new `editor` settings group to indicate that these settings only affect the UI rather than the API
- `editor_default_email_recipients` controls overall behaviour, string/enum with these allowed values:
- `'disabled'`: no option to send email is shown in the editor's publishing dropdown
- `'visibility'`: (default) selected member segment is dynamic and matches the post visibility filter
- `'filter'`: specific member filter defined in `editor_default_email_recipients_filter` setting
- `editor_default_email_recipients_filter` is an NQL string for selecting members, used when `editor_default_email_recipients` is set to `'filter'`
- default value is `'all'`
- the segment string can be any valid NQL filter with the additional special-case values of `'all'` and `'none'`
refs 829e8ed010
- i18n is used everywhere but only requires shared or external packages, therefore it's a good candidate for living in shared
- this reduces invalid requires across frontend and server, and lets us use it everywhere until we come up with a better option
- Having these as destructured from the same package is hindering refactoring now
- Events should really only ever be used server-side
- i18n should be a shared module for now so it can be used everywhere until we figure out something better
- Having them seperate also allows us to lint them properly
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this is where it starts to get fiddly as the getActive function in themeService index is required across the frontend/backend mostly due to its use in the getApiVersion method
- for now left one usage of the getActive method in place in ghost-locals middleware ready for the next phase of the refactor, which will move some of the themeService index into a shared location
refs c873899e49
- as of `bson-objectid` v2.0.0, this library exports the function
to generate an ObjectID directly, and then you need to use `.toHexString()`
to get the 24 character hex string - 6696f27d82
- this commit removes all uses of `.generate()` and replaces with this
change
