When we request all members, what happens is that the amount of data is
so great that Ghost is completely overwhelmed - database connections
are hanging open, spanners are thrown in the works, half the team are
staying up half the night!
no issue
- the members stats service was being used for the total member count
when checking member limits for publishing but the stats service is not
always correct which could result in publishing being blocked
unexpectedly
- switched to using the total count from a `/members/` query which
should always be correct/match other counts within the UI
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
The `config` service has been a source of confusion when writing with modern Ember patterns because it's use of the deprecated `ProxyMixin` forced all property access/setting to go via `.get()` and `.set()` whereas the rest of the system has mostly (there are a few other uses of ProxyObjects remaining) eliminated the use of the non-native get/set methods.
- removed use of `ProxyMixin` in the `config` service by grabbing the API response after fetching and using `Object.defineProperty()` to add native getters/setters that pass through to a tracked object holding the API response data. Ember's autotracking automatically works across the native getters/setters so we can then use the service as if it was any other native object
- updated all code to use `config.{attrName}` directly for getting/setting instead of `.get()` and `.set()`
- removed unnecessary async around `config.availableTimezones` which wasn't making any async calls
no issue
- bumped dependency
- fixed all new lint failures
- removed deprecated `ember-cli-eslint`
- it was tying us to an old version of `eslint` resulting in missing rule definition errors when linting was run as part of `yarn dev` and `ember test`
- we run linting separately in CI so we don't need linting to run _again_ on each of our ember test runs
refs https://github.com/TryGhost/Team/issues/1583
- When adding a newsletter, check the limits (both via button and route)
- When unarchiving a newsletter, check the limits
- Bumped `@tryghost/limit-service` package, required to make limit checking work for newsletter
- Added the `getNewslettersCount` query to the `limit` service
refs https://github.com/TryGhost/Team/issues/587
- Previous behavior wa showing a generic API error in the top banner which wasn't ideal UX
- With these changes user is informed about the limitation before performing any action with clear call to upgrade through the billing page
no issue
- The modal only appears when the user hits a limitation trying to activate a custom theme not part of the allowlist (if the custom theme allowlist is configured)
- Changed the upgrade button to green to match the design
refs https://github.com/TryGhost/Team/issues/587
- This is first pass on the frontend limit-service integration. Max count queries are substituted with HTTP requests to mimick backend checks. Note, they are not meant to substitute backend checks only to suplment them.
