refs https://github.com/TryGhost/Team/issues/1387
This will allow us to move from the portal_products and portal_plans
settings to using the visibility property on tiers to determine whether
or not a tier should be visible in Portal.
This also fixes a bug with the Tiers Admin API read method permissions.
- we catch error arising from creating webhooks and check for specific codes
- if our error does not match one of those codes, we don't propagate the
error up
- this becomes a problem if saving a webhook fails for some other reason
because upstream code assumes we return an error or model
- this commit re-throws the error and adds a test that would have caught
this
refs https://github.com/TryGhost/Team/issues/1004
Replaces {{products}} helper usage with updated {{tiers}} helper. Default output for {{tiers}} helper is the same as {{products}} helper.
refs https://github.com/TryGhost/Team/issues/1004
- adds new `{{tiers}}` helper behind `multipleProducts` flag
- `{{tiers}}` outputs a string with list of tiers that have access to specific post when used in a post context in theme
- outputs empty string when used out of a post context and without access to `visibility` property
- uses tiers attached to post column for data
refs https://github.com/TryGhost/Team/issues/1004
The `tiers` column for a post/page only contained data if its visibility is set to `tiers`, otherwise its empty. This is because originally the purpose of `tiers` column on `post` was to capture specific tiers with access to post.
The best way to ensure a consistent behavior for `tiers` column data on post is to update it to always contain list of all `tiers` that have access to post, and not just when the visibility is `tiers`. This means the value is set to all tiers when visibility is one of public|members, and only paid tiers when visibility is `paid`. This change also allows on frontend to get all relevant `tiers` information for a post locally within post context instead of relying on additional information from outside.
This change -
- updates the output serializer for post/page to add all desired tiers manually in case of visibility is not `tiers`
- updates tests
- We have an existing pattern for using `visibility: public` instead of `visible: true|false`
- We no-op the existing migration and roll forward so that we don't have to manually revert db changes
refs https://github.com/TryGhost/Team/issues/1367
- The {{access}} property of a post always returned false for non-public content
- Added the member context to the get, next-post and prev-post helpers
- The get, next-post and prev-post helpers didn't add the member context to the internal API calls
- Added the members context to these calls
- Added tests that check if the member context is passed to the API calls
- Transformed next_post helper tests to async await syntax
- Transformed prev_post helper tests to async await syntax
refs https://github.com/TryGhost/Team/issues/1386
- The current match handler supports normal (in)equality operators, but no numeric comparisons (<, >, <=, >=)
- A use case for these new operators is to show the latest post in a separate way from other posts
Includes unit tests to check the new behaviour.
Run via `yarn test test/unit/frontend/helpers/match.test.js`
refs https://github.com/TryGhost/Team/issues/1313
When adding the tiers endpoint the Content API was missed, this is
needed so that themes can access Tiers via the `{{#get}}` helper.
refs https://github.com/TryGhost/Toolbox/issues/169
- Before next major version release we need to prepare for removal of API versioning.
- This change allows unversioned API requests to work under following endpoints:
- /ghost/api/admin
- /ghost/api/content
- This change should allow further preparation of the API clients (SDKs, Integrations, etc.) to non-versioned APIs in Ghost instances in ^5.0.0
- Changed default e2e test targets to non-versioned API. It's a trial, to have working examples. In the future all tests should switch to use only non-versioned endpoints.
refs https://github.com/TryGhost/Toolbox/issues/169
- As Ghost prepares to drop API versioning in future major release it the authentication mechanism should take into account non-versioned token audience support. The audience for non-versioned api requests would be limited to "admin" rather than "canary/admin"
refs https://github.com/TryGhost/Team/issues/1362
- Casper is already installed, so the installation from github always fail.
- There is no need to display an error message in that case.
Added regression tests for blog setup with the default theme:
- Check whether there are no notifications after completing the setup
- Also test the setup with the default theme
refs https://github.com/TryGhost/Team/issues/1306
- This adds a `MemberPageViewEvent` event when a page is viewed by a member (post/page/tag/author/...)
- Integrates the `LastSeenAtUpdater` service that listens to the `MemberPageViewEvent` events to update `member.last_seen_at`
- Follows the latest testing recommendation (end to end test + testing for side-effects)
refs https://github.com/TryGhost/Team/issues/1387
We are moving away from the portal_products setting to instead store
each tiers visiblity on the tier itself. This column will be used for
that data.
Both of the default Tiers should be visible, but newly created tiers
should not be.
refs f48892028d
refs 33da584161
- There was another mather added recently: anyDateWithTimezoneOffset. The naming of date-related matchers was getting long and confusing. Renamed existing date matcher to better reflect what they do and they types of matches they are responsible for, following renames have been done:
- anyShortDate -> anyISODate
- anyDate -> anyISODateTime
- anyDateWithTimezoneOffset -> anyISODateTimeWithTZ
refs https://github.com/TryGhost/Team/issues/1382
- Added two possible new setup values: `accentColor` and `description` to define the brand colour and site description on initial setup
- Updated tests to reflect those changes
- Only the params when passed and fall back to default site description
refs https://github.com/TryGhost/Team/issues/1313
Rather than removing the /products API we're adding a /tiers API as
a first step towards renaming "products" to "tiers". The initial idea was
to alias the URL's but out API framework doesn't easily allow for this so
we've duplicated it instead.
refs https://github.com/TryGhost/Toolbox/issues/215
- The conversion should serve as a reference test. Eventually the aim is to have all tests converted to use "utils/e2e-framework" instead of previously used plethora of utils and whatnot
refs https://github.com/TryGhost/Toolbox/issues/215
- The conversion should serve as a reference test. Eventually the aim is to have all tests converted to use "utils/e2e-framework" instead of previously used plethora of utils and whatnot
refs https://github.com/TryGhost/Toolbox/issues/215
- The conversion should serve as a reference test. It was also a massive LoC drop when converting, felt almost criminal not to do it!
refs https://github.com/TryGhost/Toolbox/issues/215
- The ContentAPI needs it's own test agent, so we can write e2e tests.
- The main method mostly to be used by the test suites is "authenticate" - it add necessary authentication keys to the request. The agent is not authenticated by default because there are suites that need to test the "non authenticated" requests. Also, there's a need to have the default API key inserted from fixtures level before authenticating (it's not strictly necessary because the key is not dynamic, but I think coupling this point would be a bad move)
refs https://github.com/TryGhost/Toolbox/issues/215
- Ghost tests had difficulty running sometimes when the versions for jest-snapshot package did not match in Ghost and @tryghost/express-test
- This is the error that was showing up: `IncorrectUsageError: Unable to run snapshot tests, current test was not configured`
- The reason why snapshot tests were misconfigured was multiple instances of SnapshotManager, which broke the singleton pattern
- Having jest-snapshot embeded within express-test makes sure the versions stay the same across the clients
- The version bump also introduces passing "queryParams" parameter into the Agent constructor - enables configuring query parameters that would appear in each agent's request. Example usecase - Content API authentication parameter "key" would be nice to "remember" and add to every request URL
- I recently added a bunch of strict rules to our eslint plugin around returns: ca9af37866
- These mostly are issues that occur whilst writing code, that you spot and fix as you're developing, but they're annoying to notice/find and eslint can be used to flag them quickly
- There are of course, edge cases where you don't need to return from array fns, but this rule also suggests better patterns might be available
- For our excert helper and new assertEvent helper, I've updated the code to use simpler patterns that are easier to read, so as to avoid the warnings
- For our old API I've simply disabled the rule as we're about to delete this code
refs https://github.com/TryGhost/Toolbox/issues/214
- Disconnected Stripe state is now a special case after the defaul test configuration was changed to have fake Stripe keys included mimicing configured Stripe
- The disconnected state is now achieved through an API call instead of mocking internal services from the test level. This seems like a cleaner approach, although still a bit cumbersome
refs https://github.com/TryGhost/Toolbox/issues/214
- These variables need to be present in the configuration during the Ghost's boot time initialization, which caused a need to remember to mock settings cache before agent initialization.
- By moving the values into default settings config it removes the need to do any work during test environment setup. Yey!
- We should put default values in to test-specific settings-defaults.json In similar situations. Specifically, when we find a need to mock settings cache to be able to start Ghost instance in a certain state
refs https://github.com/TryGhost/Toolbox/issues/214
- Having this config for test environment allows to pre-populate default settings values in the settings table
- Right now the default-settings.json is an exact copy of the original "/data/schema/default-settings/default-settings.json". Having a starter file as an exact copy, allows to track the differences between environments as they are introduced easier
refs https://github.com/TryGhost/Toolbox/issues/214
- The values configuration for the settings table need to become configurable to be able to run our test environment with a pre-defined set of configurations (e.g Stripe-related values).
- This change makes it possible to define the default settings file location (currently a JSON)
- A new key is now exposed through the "paths.defaultSettings" key in settings, which can be overloaded for the needs of the environment
refs https://github.com/TryGhost/Toolbox/issues/214
- The `defaultSettings` path name in the config (one pointing to routes yaml file) creates confusion with the `defaultSettings` which populate defaults for in the database settings table.
- Furthermore, the name collision creates a problem when trying to make database default settings dynamic - being able to load them from configurable file path.
- Rename makes "routing" explicit to avoid ambiguity and free up the name for the database defaults
- The value seems to be safe to be renamed as all keys used in `overrides.json` are taking priority - the name "defaultRouteSettings" hasn't surfaced at any point in the git history
refs https://github.com/TryGhost/Toolbox/issues/214
- TestAgent was used to initialize both Admin & Member API agents, which is somewhat confusing because Member API does not have the same "loginAs" functionality like Admin API does
- Having distinct agents for each API makes the class API cleaner with possibility to extract common functionality even further
- Fixed test fixtures so that members with subscriptions also have products/tiers
- Fixed test fixtures so that default&free tiers can be updated for tests
- Added tests for the signin functionality and welcome page redirects
- Extended `setupStripe` to setup other Members settings - this needs some more
thought around how we proceed
refs https://github.com/TryGhost/Team/issues/1355
- Uses the models to query the database for testing the event presence.
- Prototyped an util to help with event assertion and correct error messages and lower lines of codes.
- Given there are side-effects between tests (adding or removing members), the event count depends on the previous tests, this isn't optimal.
- the previous logic only allowed one flag to be mocked at a time because it kept recalling sinon.stub
- now it's possible to mock multiple flags with different settings as we always just add to the same stub
no issue
- The test was failing because the match for a the data has changed, which was returned in a short format YYYY-MM-DD.
- Added a new matcher for short date format -anyShortDate. Can be used for match dynamic dates in short format
