no refs
With custom products, we added a new modal to add a complimentary price to a member. Since we want to handle the comp prices implicitly with new changes, this change updates the comp subscription assignment to a member directly without opening a modal, by using the old `comped` flag in API. The `comped` flag takes care of creating the right complimentary subscription for member.
In case a member already has a comped subscription, we hide the option to add another subscription.
no refs
Portal plan settings are updated on the membership page when the plans are changed, but its not reflected in Portal settings because we were not updating the array the ember way.
no issue
On the membership screen we save settings before opening the portal settings modal but we weren't waiting for the save to finish which meant that the portal settings modal could load using stale data.
- passed the save settings task in via the portal settings modal's model
- added a `finishPreloading` action that contains all of the dynamic setup tasks that were previously in the component's `init` method
- if a preload task was passed in and it's currently running (as it would be if the modal is opened via the membership screen button) then it will wait for the task to finish before running the setup tasks
- trigger the `finishPreloading` action when the modal is rendered
- show a loading spinner in place of the modal contents whilst pre-loading
refs https://github.com/TryGhost/Team/issues/598
Stripe Webhooks require SSL in production, and so we should not be
allowing connecting to Stripe in production mode unless the site is
running with SSL. This change -
- Updates Setup wizard to skip Stripe Connect steps if site is not on SSL in production
- Adds warning on set subscriptions page
Co-authored-by: Peter Zimon <zimo@ghost.org>
no refs
Portal preview on membership settings reflects the currently set monthly/yearly price directly by passing in the updated amount to portal preview URL
no issue
- added `@onDestroyed` argument to `<GhSiteIframe>` so consumers can clean up any references
- used `@onLoaded` and `@onDestroyed` to handle a reference to the preview iframe
- updated portal preview load handler and update method to trigger a resize task
- add a 100ms delay to allow for portal to re-render itself
- reach through the two iframes to get the portal container element and use it's height to set the style attribute on the portal preview container element
no refs
Portal plans setting contains list of prices that are allowed by site owner to use in Portal UI. Since we now switch monthly/yearly prices dynamically, we need to update portal plans on price change to still reflect updated monthly/yearly prices in Portal UI.
no issue
- added `@invisibleUntilLoaded` boolean argument to `<GhSiteIframe>`
- when set to true add `.invisible` class until iframe's `load` event is triggered
- removed manual iframe hiding with 1.2sec delay from portal settings modal
- added `@onLoad` argument to `<GhSiteIframe>` for consumers to hook in if needed
no refs
We only want to show currently active monthly/yearly prices in Portal and Portal settings based on new settings for price ids, and hide all other prices
no refs
Previously, we were fetching product and prices in the constructor of the controller which did not guarantee settings were updated when picking active prices from the price list. This updates the setup to use `did-insert` modifier to correctly fetch and populate product/price data.
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 4627d1c26a
- Adds new settings for monthly/yearly price ids in the settings modal
- Updates logic to save product on membership settings - Creates new prices for monthly/yearly when it doesn't exist, updates the monthly/yearly price ids in the settings
- Fixes selected currency value in dropdown
no refs
- Wired Premium membership UI to existing monthly/yearly prices in the default product
- Wired free membership UI to redirect URI setting
- Updated save to validate settings/errors
no issue
- added actions for handling close/confirm/cancel of portal settings rather than re-using the route-level leave modal because the portal settings modal does not need any knowledge of the route
- added controller reset that is called when the route is exited to ensure no modals are shown when navigating back to the membership screen
- fixed "cannot set on destroyed" error when portal settings are opened and closed quickly
- removed usage of old `{{action}}` helper - this has been replaced with `{{on}}` and `{{fn}}`
no issue
- we're currently limited to a single product so it doesn't make sense to show it as an option as it creates two different routes to "paid members" that we'd like to avoid for now
no issue
- add icon + icon color to the subscription access and default post access option lists
- updated templates to use icon in trigger and option display
- fixed ember-power-select styles overriding svgs in trigger
refs https://github.com/TryGhost/Team/issues/581
Setting post visibility to a label results in undesirable and confusing behaviour with no good way to manage access long-term. Coupled with products being limited to a single product for now we're reverting the UI back to the "Public", "Members", and "Paid" options.
no issue
- provides clearer indication of current setting without having to expand anything
- has more minimal UI which helps when settings screen has multiple areas
no issue
- the membership setting screen will be covering a lot of areas, having individual settings as discrete components allows for easier re-organisation and cleaner parent templates and controllers
no issue
Members related settings are being consolidated into a single screen.
- renamed access to membership as the starting point for redesign and consolidation of other settings screens
