refs https://github.com/TryGhost/Team/issues/2204
This was found during Tiers flows testing, the logic for fetching
price information from Tiers had not been updated to use the new Tiers
package and Payments service. This only affects Tiers created since 5.22.x
closes https://github.com/TryGhost/Team/issues/2207
- adds conditional to the post email serializer to switch between
`mobiledocLib` and `lexicalLib` depending on which format the post
contains
closes https://github.com/TryGhost/Team/issues/2211
We were allowing paid Tiers to be imported with non-integer prices which was
causing the Admin to be bricked when attempting to load them. This adds some
validation to the price data of Tiers.
- the create-release-branch workflow works by getting the most recent
tag, bumping it and using that to create the new tag
- now we've moved Portal into the monorepo, we've got two different
types of flags, but the Portal ones aren't valid semver so the
workflow fails if the most recent tag is one for Portal
- this fixes that by ensuring we only fetch tags matching the pattern we
use for tagging Ghost
refs https://github.com/TryGhost/Team/issues/2110
- dynamically defined properties on the config service did not have
autotracking set up properly if they were accessed in any way before the
property was defined, this caused problems in a number of areas because
we have both "unauthed" and "authed" sets of config and when not logged
in we had parts of the app checking for authed config properties that
don't exist until after sign-in and subsequent config re-fetch
- renamed `config` service to `configManager` and updated to only
contain methods for fetching config data
- added a `config` instance initializer that sets up a `TrackedObject`
instance with some custom properties/methods and registers it on
`config:main`
- uses application instance initializer rather than a standard
initializer because standard initializers are only called once when
setting up the test suite so we'd end up with config leaking across
tests
- added an `@inject` decorator that when used takes the property name
and injects whatever is registered at `${propertyName}:main`, this
allows us to use dependency injection for any object rather than just
services or controllers
- using `application.inject()` in the initializer was initially used but
that only works for objects that extend from `EmberObject`, the
injections weren't available in native-class glimmer components so this
decorator keeps the injection syntax consistent
- swapped all `@service config` uses to `@inject config`
no issue
- added cleanup of the `message` event handler added to `window` when the component is destroyed
- added a guard to the event handler method to abort early if a message is received whilst the component is being destroyed
closes https://github.com/TryGhost/Team/issues/2110
- added failing test showing feature service `@feature` properties
weren't autotracking correctly if accessed before
authentication+settings fetch occurs
- shows labs and feature properties on the feature service are not
reacting to changes in the settings service
- removing the `@computed` on the `feature.labs` getter stops it being
cached but it then fails on the `feature.testFlag` computed property
- updated `settings` service to behave as expected with our current
version of Ember
- inspected the store schema for `Setting` to define the "proxied"
properties up-front rather than only after fetching
- updated the property definition to use `computed` so we're opting in
to the old style reactivity (required adding the `@classic` decorator to
pass linting)
refs https://github.com/TryGhost/Toolbox/issues/461
- The 'vary' header with 'Origin' value should only be set when an OPTIONS header is processed. Otherwise we are prone to leaking the vary header modification to further down in the request pipeline
refs https://github.com/TryGhost/Toolbox/issues/461
- The unit test was never using the "OPTIONS" request method, which did not actually trigger the full logic of the "cors" module used under the hood.
- Using the correct request method triggers all the right pathways and tests the state that's closer to the real world - for example the response does get "ended" instead of calling the "next" middleware.
closes https://github.com/TryGhost/Team/issues/2202
Some parts of the codebase were not using the isSameCurrency helper
which meant that we were incorrectly filtering out tiers from the
upgrade screen. Tiers used to *usually* have a lowercased currency
property, but they now _always_ have an uppercased.
refs https://github.com/TryGhost/Toolbox/issues/461
- Having a 'Origin' in vary header value present on each `OPTIONS` allows to correctly bucket "allowed CORS" and "disallowed CORS" responses in shared caches
refs https://github.com/TryGhost/Toolbox/issues/461
- Having a 'Origin' in vary header value present on each `OPTIONS` allows to correctly bucket "allowed CORS" and "disallowed CORS" responses in shared caches
refs https://github.com/TryGhost/Team/issues/2199
The data-attribute handler was not using the utils/api package but
instead reimplemnted the logic to create checkout sessions, this was
missed when moving to a redirect for checkout and so wasn't working
correctly.
closesTryGhost/Team#2094
This value can be used for non-crucial data with a `public` option. For example: `public, max-age=1, stale-while-revalidate=9`.
The idea behind this option is that the browser would cache the value for the number of seconds in `max-age` and would use it for the number of seconds in `stale-while-revalidate` until it gets a "validated response" from the server. The behaviour should be almost unnoticeable for the end user but would make a big difference in the amount of requests to server.
refs https://github.com/TryGhost/Toolbox/issues/461
- The codebase has ambiguous behavior with OPTIONS request. Adding tests covering edge cases for all possible variations of OPTIONS responses is the first step to solving cahceability of these requests.
- The obvious question if you look into the changeset itself would also be: "WTF did you do with test suite naming? What are these changes in admin and click tracking suites? You having a bad day Naz?". The answer is "yes" (╯°□°)╯︵ ┻━┻
- On a serious note. I've introduced multiple hacks here that should be fixed:
1. Forced test suite execution order for options request - extreme blasphemy. This was last resort decision. I went deep into trying to fixup the server shutdown in the "admin" test suite, which cascaded into failing "click tracking" suite, which has shortcomings on it's own (see notes left in that suite)
2. Exposed "ghostServer" from the e2e-framework's "getAgentsWithFrontend" method. Exposing ghostServer to be able to shut it down (or do other manipulations) was one of the pitfalls we had in the previous test utils, which ended up plaguing the test codebase. Ideally the framework should only be exposing the agents and the rest would happen behind the scenes.
- To fix the hacks above I've raised a cleanup issue (https://github.com/TryGhost/Toolbox/issues/471). I'm very sorry for this mess. The issue at hand has very little to do with fixing the e2e framework, so leaving things "as is".
refs https://github.com/TryGhost/Toolbox/issues/461
- When testing OPTIONS requests there is a need to get all possible agents available in the system. The "getAgentsWithFrontend" serves exactly this purpose - create all possible agents while starting Ghost instance only once
- This is groundwork for OPTIONS request caching tests and improvements
