- as per 5a5a5d162e, the Bookshelf registry plugin is now in core
- we no longer need to explicitly load the plugin, and it displays a
warning if you do
- this change also turns `._models` into `.registry.models`, so our code has
been updated to reflect that
- Bookshelf now seems to error out when the response is undefined and
expects something
- this commit updates the test to the same empty response we use
elsewhere
- as per https://github.com/bookshelf/bookshelf/wiki/Migrating-from-0.15.1-to-1.0.0#default-to-require-true-on-modelfetch-and-collectionfetchone, models will now default to `{require:true}` during a fetch, which changes how Bookshelf will respond when a models yields no results
- instead of passing a `null` result, it will reject with an error, so we'd need to switch to `.catch`ing everything
- our code is set up to handle all these null results and switching style is not currently on the cards so we want to use the existing behaviour for now
- to enable this, the `requireFetch` option needs to be added to the model definitions
refs https://github.com/TryGhost/Team/issues/1030
The usage of `setComplimentarySubscription` is for pre-Tiers enabled
sites only. We didn't see this issue before because the `comped` flag
was incorrectly being set to `false` by default. Since it was fixed in
https://github.com/TryGhost/Ghost/commit/ae844db60 the `comped` flag was
then getting sent up, and creating the subscription.
We've moved the usage of `setComplimentarySubscription` to behind the
feature flag so that we do not use old behaviour when Tiers are enabled
refs https://github.com/TryGhost/Ghost/pull/13276
- when removing the labs flag a conditional in the email processor checking for the labs flag being enabled was replaced with a check for a member segment being present. This meant that email batches with `member_segment: null` representing all members that didn't have content specifically aimed at them were not having the segmented content stripped before sending
refs https://github.com/TryGhost/Team/issues/1004
- adds new `{{products}}` helper behind `multipleProducts` flag
- `{{products}}` outputs a string with list of products 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 all available posts for a site via the global products data
- updates {{content}} helper cta to use this new helper to show list of tiers with access to post
refs 025eb8bd79
`mutipleProducts` has now been moved out of alpha to beta, though the alpha feature tests were still using it to verify alpha behavior. The tests are now updated to use `dashboardTwo` feature as base alpha feature instead.
refs https://github.com/TryGhost/Team/issues/1026
Tiers is moving up as a beta feature with an early-access opt-in flow. This means site owners can now opt-in for early access to Tiers feature in Ghost, but it's a one way door and its not possible to switch off tiers once enabled. This is to ensure that sites don't break in any unexpected ways once the tiers feature is enabled by switching it off.
no issue
- this package has been bumped to support Node 12 + 14
- AFAICT I added it to the Renovate list back when we had some timezone
issues with moment, but we've since pinned the version of moment so we
shouldn't experience that now
- therefore this commit also removes it from the Renovate ignore list
no-issue
The webhook handler did not correctly check for whether or not Stripe
was connected, and would attempt to handle webhooks anyway, resulting in
errors due to missing Stripe config. This fixes the handler to exit
early.
no issue
- Renovate will open PRs to bump dependencies but these are unassigned
- Renovate does have the ability to set assignees, but these are blanket
assigns not based upon the package that is being upgraded
- we want to assign them to the owners of the package that is being
upgraded
- I've created the `gh-auto-assign` GitHub CLI exntension which reads a
`.github/AUTO_ASSIGN` file and assign PRs based upon the entries listed
- this commit adds the initial `AUTO_ASSIGN` file and GitHub Actions
workflow to trigger when a PR is opened
refs https://github.com/TryGhost/Team/issues/1006
The @tryghost/members-api module has been updated to remove webhooks
from Stripe when disconnecting. This will ensure that we do not leave
around old/invalid webhooks that will not be handled and generate
errors.
refs https://github.com/TryGhost/Team/issues/1006
Moving the logic of disconnecting Stripe into the members-api module
decouples the Ghost API from the Members API internals. This method can
now be updated independently of Ghost, to implement the deletion of
webhooks from Stripe.
refs https://github.com/TryGhost/Team/issues/1000
Some free members were created with a status of 'comped', this resulted
in MemberStatusEvents being created with a `to_status` of 'comped'.
In 4.12 we fixed the status for all free members, but we did not update
the associated member_status_event.
refs https://github.com/TryGhost/Team/issues/995
Since we reintroduced the comped status, we did not update the
subscription handling to correctly set members to a status of comped
when they were on a 'Complimentary' plan. This meant that 'comped' members
had a status of 'paid'. The changes to @tryghost/members-api ensure that
handling subscriptions going forward will not result in this error.
Since we handle the Complimentary plan correctly now, we do not need to
manually check for the existence of one, we can instead rely on the
status to set the `comped` flag.
* Migrated members comped status to reflect subscriptions
refs https://github.com/TryGhost/Team/issues/995
Due to a bug in subscription handling, members with Complimentary stripe
subscriptions were incorrectly given a status of 'paid'.
The goal of this migration is to fix existing broken members, and it
will be accompanied by a fix which prevents the bug for future members.
Since we are updating the status properties for members, we must ensure
that we also update the relevant member_status_events entries too, so
that we do not have incompatible sums between events and statuses.
For example, if we were to use events to graph comped members over time,
we would want the current count to match the query on statuses:
`SELECT COUNT(*) FROM members WHERE status='comped';`
refs https://github.com/TryGhost/Ghost/issues/12942
The function signature of this method has changed, and was only updated
in the canary API, this meant that API requests attempting to link a
stripe customer to a member would error for the v3 API.
no-issue
The ProductRepository changed to require the options parameter which is
not passed when created complimentary subscriptions. This updates the
code to no longer require the options parameter and instead provide a
default.
closes https://github.com/TryGhost/Team/issues/1024
Our importer would set the default value of all posts_meta keys to
`null`. This is an invalid value for the `email_only` key which only
accepts booleans.
Since we are already looping over the schema to create the default
values, we can use the `defaultTo` property in the schema to use the
intended default, and fall back to `null` if it doesn't exist.
We've used the `Reflect.has` function to determine if the `defaultTo`
key exists, as opposed to a truthy check, because it's possible that a
falsy value (e.g. false, in the case of email_only) can be used as the
default.
no-issue
The ProductRepository changed to require the options parameter which is
not passed when created complimentary subscriptions. This updates the
code to no longer require the options parameter and instead provide a
default.
closes https://github.com/TryGhost/Team/issues/1024
Our importer would set the default value of all posts_meta keys to
`null`. This is an invalid value for the `email_only` key which only
accepts booleans.
Since we are already looping over the schema to create the default
values, we can use the `defaultTo` property in the schema to use the
intended default, and fall back to `null` if it doesn't exist.
We've used the `Reflect.has` function to determine if the `defaultTo`
key exists, as opposed to a truthy check, because it's possible that a
falsy value (e.g. false, in the case of email_only) can be used as the
default.
refs https://github.com/TryGhost/Team/issues/694
- The canary schedules controller was refactored to use newly introduced post-scheduling service in a previous commit. This is a follow up to match v2/v3 controllers as they had identical code to the canary one.
refs https://github.com/TryGhost/Team/issues/694
- The controller code is not meant to contain complex business logic.
- Kept the pattern used in all modules under services/themes. The install module shold be refactored into a class with DI pattern when touched next.
refs https://github.com/TryGhost/Team/issues/694
- Additional try/catch block needed in async/await implementation increased method complexity and broke the complexity linting rule. This is a dirty way to fix the warning. Ideally the implementation should stay with async/await syntax and instead move the custom error handling logic into some different layer. For example we could introduce a separate "stage" in the API framework's "pipeline" where we'd catch and handle in a generic way all of the "unique" types of errors. It would make sense to have a generic handler because this same code happens in labels, member and few more places.
