- Preparing to cleanup / change how we use events across Ghost
- Removing this unused bit of additional complexity makes it easier to reason about what we need
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
refs https://github.com/TryGhost/Team/issues/579
The previous `members_allow_free_signup` -> `members_signup_access` migration made a direct correlation between the toggle `true/false` to `all/invite` under the assumption that behaviour between the two settings would be identical. The assumption was incorrect and the behaviour is changing so `invite` forces invite-only mode, stopping all front-end signup to free or paid plans with the free plan now being disabled via the portal plans setting.
- check existing `members_signup_access` setting and if it's `'invite'` migrate it to `'all'` where signup should still be possible. The "invite-only" mode should only be active if certain conditions are met:
- Stripe is not configured ("allow free member signup" off and no Stripe showed "invite-only" in portal)
- Stripe is configured but no plans are selected in portal (no plans showed "invite-only" in portal)
- when migrating `'invite'` to `'all'`, also remove `'free'` plan from the `portal_plans` setting to avoid previously paid-only sites unexpectedly showing a free plan on signup
refs https://github.com/TryGhost/Team/issues/634
- find earliest backup file created when a 4.3 migration was run, if found use the `members_allow_free_signup` value from there to change `members_signup_access` from `'all'` to `'invite'` if necessary
- 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 https://github.com/TryGhost/Team/issues/588
- This check allows for a on/off switch to be set up on the instance and control limits around sending emails
- An example configuration for such check would look like following in config's hostSettings section, e.g.:
```
"emails": {
"disabled": true,
"error": "Email sending has been temporarily disabled whilst your account is under review."
}
```
refs https://github.com/TryGhost/Team/issues/637
refs https://github.com/TryGhost/Team/issues/591
We need to run migrations which will update the `portal_plans` setting
to use id's rather than names. This migration relies on the
`stripe_prices` table being complete populated. The migration to
populate the `stripe_prices` table was not added as a "normal"
migration because it needs to access the Stripe API over the network.
Any migrations that rely on this are unable to be run in a "normal"
migration as that cannot be sure that the database is in the correct
state.
The `portal_plans` setting migration is therefore run in code, and needs
access to the Settings model in order to modify the database.
closes https://github.com/TryGhost/Team/issues/645
- we did some refactoring in [1] to turn promise chained code into
async/await, but this removed an early `return` from the code
- therefore we'd continue on to further code, which breaks for obscure
reasons that weren't apparent from the error
- this commit adds back a return at the end of the block where we handle
staff API tokens to match the same functionality as before
- this is regression that landed in 4.3.0 and would break staff user
tokens
[1]: b677927322 (diff-bc0bedcac8ec9646d0644c86a91e46f4759bc1b0c2aebac54a2b26ec474c3d15L148-L155)
refs https://github.com/TryGhost/Team/issues/579
Updates minimum Portal version to handle the new `members_signup_access` setting and explicitly handle the `invite` option to make Portal work in invite only mode if selected
refs https://github.com/TryGhost/Team/issues/634
- the migration moving `members_allow_free_signup` to `members_signup_access` was expecting a raw boolean setting value but the actual value is a string so always evaluated as truthy making all sites look like they had "allow free members signup" toggled on when generating the new setting's value
- updated to check for an explicit string value in `up` and set an explicit string value in `down`
refs https://github.com/TryGhost/Team/issues/579
The new signup access setting allows site owner to set the type of access level allowed for a member which Portal needs to handle
refs https://github.com/TryGhost/Team/issues/579
`members_signup_access = 'invite'` now forces invite-only mode so both free and paid setups both use the `'all'` setting. To ensure we're properly allowing/disabling free (self signup) signups in the members API we need to update `allowSelfSignup()` to take additional settings into account.
- `true` when Stripe is not connected. There are no paid plans available in this configuration so free signup is always enabled. To disable free signup on a site with no Stripe setup the members signup access should be set to `invite` or `none`.
- `true` when Stripe is configured and free plan is enabled in portal, without it Members API would not send magic link emails to signup requests
- `false` in all other situations such as invite-only and members-disabled signup access modes, or when the free plan has been disabled in portal configuration
refs https://github.com/TryGhost/Team/issues/634
- the migration moving `members_allow_free_signup` to `members_signup_access` was expecting a raw boolean setting value but the actual value is a string so always evaluated as truthy making all sites look like they had "allow free members signup" toggled on when generating the new setting's value
- updated to check for an explicit string value in `up` and set an explicit string value in `down`
refs: bf0823c9a2
refs: ae86254972
- continuing the work of splitting up the theme service into logical components
Themes Service
- The serverside theme service now serves just the API and boot
- It loads the theme and passes it to the theme-engine via the bridge
This achieves the bare minimum goal of removing all the cross requires between server and frontend around themes
There is still a lot more to do to achieve an ideal architecture here as laid out in ae86254972
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- am about to move the theme service to core/server so it should require i18n directly
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- this file is not part of the theme engine so it should use the bridge not the engine
- am about to move the theme service to core/server so this will make even more sense then
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
Theme activations are a trickier piece of the theme split puzzle because they are called from the API and theme service on boot in different ways.
Activations require a theme to have been validated at different levels. Validations are also tricky - do they belong to the theme engine, or the theme service?
There are then several different flows for activations:
- On Boot
- API "activate" call
- API override on upload or install via setFromZip, which is a method in the storage layer
These calls all have quite different logical flows at the moment, and need to be unified
For now, I've moved the existing "activate" function onto the bridge. This allows the theme service to be split from the frontend, and refactoring can start from there.
I hope to move this so there is less code in the actual bridge very soon, but my goal is not to require any server packages in the frontend part of this
I think ideally:
- all activation code, including validation, should probably be part of the theme engine
- the theme engine should offer 3 methods: getActive() canActivate() and activate()
- the theme service is then only responsible for loading themes in and out of storage, JSON responses for the API, and handing themes to the frontend via the bridge at the appropriate moment
refs https://github.com/TryGhost/Team/issues/616
We need a way to assign Products to Members via a Subscription, and we've
followed the same pattern as the editSubscription method for the Members API
controller, which acts upon Subscriptions as a nested resource.
Subscriptions now are linked to products, and we've included those links by
default in the Member Admin API as we already include subscriptions by
default, and Products are now a core part of the Members feature-set.
- Modules in /shared are supposed to be standalone modules that can be required by the server or frontend
- As the server shouldn't require the frontend, and vice versa, shared modules should require neither
- Otherwise it just becomes a crutch for allowing cross-depenencies, and will create circular dependencies
The Bridge
- The bridge file is not meant to be a crutch sat allowing cross-dependencies, but rather a new component that manages the flow of data
- That data flows from the server/boot process TO the frontend, and should not flow in the other direction
- The management of that flow of data is necessarily hacky at the moment, but over time the architecture here should get clearer and better
- Still, for the time being it will need to handle requiring across components until that architecture matures
- Therefore, it should live in core root, not in core/shared
refs: bf0823c9a2
- continuing the work of splitting up the theme service into logical components
- This one is a little more involved, as the i18n initialisation was unnecessarily spread over several locations.
- I moved it into being part of the ActiveTheme class and called in the constructor, meaning we don't need the services.theme.activated event anymore as the constructor is called in the same cases.
- Also moved the event listener for locales into the bridge, as I don't want that inside of theme-engine, and we don't want circular dependencies. We'll figure out a wayto refactor this soon too.
refs: bf0823c9a2
- Added a new bridge class that lives in shared. This should eventually be responsible for all cross-communication between the frontend and the server
- Having all the gnarly shared bits in one place should help us refactor more easily
- For now it also reduces requires between the core/server and core/frontend folders that are meant to be separate
- All calls to getApiVersion have also been renamed to getFrontendApiVersion, as this is different to the "default" API version
- Slowly getting to the point where frontend/services/themes can be moved to server/services/themes :)
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
issue https://github.com/TryGhost/Team/issues/614
- Users who have a password can directly sign-in via oauth
- User who are logged-in get their password disabled
- Users accepting an invitation get their password disabled
- The way we disable password is by setting it to a long random password
refs: 9f50e941eb
refs: bf0823c9a2
- Still working towards splitting the theme service into logical components
- The engine defaults were required in the index file, in a way that creates tight coupling across what would otherwise
be distinct components
- Also meant there was another hardcoded 'v4' in the codebase
- This fixes both issues by depending on the value from config
- Currently this adds Yet Another Config Require, but it should be fine for now until we have a new pattern for the frontend
- Note: We only care about the ghost-api engine, we used to care about both ghost and ghost-api. Now that there is only one there was no need for the more complex code structures
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
refs: https://github.com/TryGhost/Team/issues/527
refs: bf0823c9a2
- We have default API versions littered all over the codebase. When we updated to Ghost v4 we realised just how many and how much of a pain in the ass this is to manage.
- This creates a config value we can use. It's in overrides for the time being because we usually default to that until there is a usecase for it being overridable. If there is one, cool, change it!
- The main motivation for adding this now and only using it in boot and urlUtils is as part of work to decouple the theme service into logical compontents, because the engines system inside of themes has its own default, and this is one cause of tight coupling
- Expectation is that we'll slowly roll out use of the new default, hopefully without requiring config in any additional places (e.g. passing the version in from the boot file)
refs https://github.com/TryGhost/Team/issues/579
- when members signup is enabled returns `#/portal` otherwise returns feedly subscription URL
- allows for themes to have subscription buttons without condititionals, eg `<a href="{{@site.signup_url}}">Subscribe</a>`
refs https://github.com/TryGhost/Team/issues/619
As part of the Custom Products work, we are linking members to products
when updating their subscriptions. This requires that we have at least
one product in the database. For existing sites that are using Members
this is handled by the v4.3 03 migration. But for new sites we must
include a fixture.
Also fixes the tests to not reply on the order of the fixtures
refs https://github.com/TryGhost/Team/issues/616
This is a basic scaffold of the API to get things moving.
The input serializer is so that the controller logic does not need to
know about the json-api shape of the input data.
The output serializer is an adaptation of the members one.
refs https://github.com/TryGhost/Team/issues/586
- Adds new `stripe_price_id` column to subscriptions table to store stripe price ids with `index`
- Populates `stripe_price_id` column value to current `plan_id` making the `plan_*` values redundant
- Updates tests
refs https://github.com/TryGhost/Team/issues/586
If a product inside Ghost is deleted, we want to cascade delete all associated Stripe products and prices as they always need to refer back to a ghost product and will hang without any reason otherwise. This change adds cascade delete for products -> stripe_products -> stripe_prices to avoid broken states
