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`
closes https://github.com/TryGhost/Team/issues/2190
- added a guard around the tier fetches in `membersUtils` service so the fetch doesn't occur unless we have a logged in user and they aren't a contributor
- extracted the `withPermissionsCheck` mirage util function and added role checks around the mocked tiers endpoints
- added an acceptance test that loads the content screen and creates a draft post as a contributor to help catch regressions
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
The `settings` 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 `settings` service by grabbing the attributes off the setting model after fetching and using `Object.defineProperty()` to add native getters/setters that pass through to the model's getters/setters. 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 `settings.{attrName}` directly for getting/setting instead of `.get()` and `.set()`
- removed use of observer in the `customViews` service because it was being set up before the native properties had been added on the settings service meaning autotracking wasn't able to set up properly
refs https://github.com/TryGhost/Team/issues/1650
- Some places only checked for Stripe being connected via the 'connect' method and ignored the 'direct' method
- Updated (where possible) admin to use the new calculated `paid_members_enabled` setting
refs: https://github.com/TryGhost/Team/issues/1145
- this should allow us to remove the /products endpoint in v5
It avoids:
- `kg-product-card`, that really is meant to say product
- `product-cadence` on offers
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
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 updates admin to handle tier visibility property based on changes in settings. Old portal settings update is temporarily kept in though will not be used for determining visibility going forward. Also removes default product visibility being set on stripe connect.
no issue
- part of ember upgrades
- removed all unnecessary usage of `.get`
- cleaned up imports where we had imports from the same module across multiple lines
- standardized on importing specific computed helpers rather than using `computed.foo`
- switched tests from using `wait()` to `settled()`
refs https://github.com/TryGhost/Team/issues/1162
- fixes decimal value for fixed type discount not working
- updates offer name placeholder to Display title
- removed default offer description value in portal preview
refs https://github.com/TryGhost/Team/issues/1137
- adds new portal preview using portal offer url on offer screen
- adds new utility to calculate portal offer preview url from data
- fixed tiny bug with discount type currency not shown correctly
no issue
Free and Paid are by far the two most common options for email recipients so it makes more sense to have them as very clear options which we felt was not the case with the single token/segment select.
- created a new `<GhMembersRecipientSelect>` component that has individual checkboxes for free/paid/segment and when segment is selected an additional token input for specific labels
- updated draft and scheduled publish menu components to use the `<GhMembersRecipientSelect>`
Co-authored-by: Sanne de Vries <sannedv@protonmail.com>
no issue
- fixed styling issues
- fixed portal preview taking over the screen by adding `position: relative` to the container
- fixed portal preview being interactive by disabling pointer events
- added portal preview URL generation to memberships controller
- moved much of the preview params knowledge/calculations from the `<ModalPortalSettings>` component into the `members-utils` service so that a portal preview URL can be generated from anywhere using current settings values rather than the method consumer needing to have knowledge of all params and how to generate them
- updated actions in controller that modify settings to also update the preview url
- added `onChange` event to the `<Settings/MembersSubscriptionAccess>` component so the controller can react and update preview
- used `<GhSiteIframe>` with generated portal preview URL for live display of portal changes on memberships screen
refs https://github.com/TryGhost/Team/issues/579
- portal reads `allowSelfSignup` from config at startup and so won't show the free plan if it was not selected when preview is first opened
- updated `membersUtils.getPortalPreviewUrl()` to duplicate the `allowSelfSignup` logic from the server so it can be passed through to portal dynamically
refs 7687571b12
While extracting the portal preview url setup to member-utils, the util incorrectly referenced values for free/monthly/yearly plans and so stopped reacting to selected plans in Portal preview. This change fixes the `isFreeChecked`, `isMonthlyChecked` and `isYearlyChecked` references in util.
refs
- dropped the portal service in favour of using the existing `membersUtils` service
- renamed `getPreviewUrl()` to `getPortalPreviewUrl()`
- update the iframe src to point to the portal preview url when on the pricing step
- added free/monthly/yearly checkboxes to pricing step
- update iframe src with regenerated portal preview params when making changes
refs #10318
* Updated settings model with new settings
* Removed parseSubscriptionSettings from settings service
* Updated members-utils to use new settings
* Updated labs controller to use new settings
* Fixed dependency for member-settings-form
* Updated members-lab-setting component to use new settings
* Updated disconnect modal to use new settings
* Updated members portal modal to use new settings
* Removed Direct from settings
* Renamed members_allow_signup -> members_allow_free_signup
* Allowed for null fromAddress
no-issue
This is now the central place for checking if stripe is configured for
members and we want to make sure that the Stripe Connect correctly
affects this value
no issue
- This logic is planned to be reused in more places, e.g. members import data validation. This change is meant to be a prep work for that.
- With stripe connect functionality coming it is important to have a central place checking for configured Stripe
