refs https://github.com/TryGhost/Team/issues/822
With multiple products flag we are re-enabling segmentation by product for posts. This change adds new segment option for post access option in post-settings menu, which allows option to choose specific products for post access.
- updates post settings and post settings labs menu to add new option for segment
- handles visibility filter changes for API based on selected segment
- the new behavior is behind the alpha flag for multiple products
refs https://github.com/TryGhost/Team/issues/822
The post access dropdown in the Post settings menu and default access settings should not show the default segments as we only allow segmenting on specific products.
refs https://github.com/TryGhost/Team/issues/803
With multiple products we'll re-enable segmentation by product for posts, which also means need to add a new option to the default post access setting in Membership settings. This change -
- adds new `A segment` option to default post access dropdown behind the alpha flag for multiple products
- shows member segment select dropdown for `A segment` option
- handles update of `defaultContentVisibility` to allow setting custom filter
refs https://github.com/TryGhost/Team/issues/849
Multiple products alpha feature brings back segmented post access using products. The new visibility filter based on segments is returned in a separate `visibility_filter` property on post/page API
refs 3d16b95e0f
- fixed linting errors
- fixed automatic clearing of invalid publish date when PSM is closed
- previously the PSM was always rendered so it had a `showSettingsMenu` argument that told it whether it was being shown
- automatic error clearing was tied to `showSettingsMenu` so it was switched to `willDestroyElement` because now the menu is re-rendered each time it's shown
- fixed tests
- tests assumed the menu was always rendered so they were manipulating inputs even though they weren't visible on screen
refs https://github.com/TryGhost/Team/issues/840
We wanted to switch to a settings menu that stays open to the right of the editor rather than a popover that blocks all other interaction with the post to solve two use-cases:
1. when editing it's fairly common to select some text from the post contents when setting excerpt and meta data text, with the previous design not letting you scroll or select whilst the menu got in the way of that
2. having the menu open with meta data visible before publishing can help you see everything is set as you want and help you feel confident when publishing/sending content
---
- removed `psmRedesign` labs flag
- swapped labs component/css for main component and deleted labs component
- cleaned up now-unused `ui.showSettingsMenu` property and related actions/classes
refs https://github.com/TryGhost/Team/issues/839
The feature image uploader in the post settings menu did not lend itself well to having additional fields so we've moved it into the main editor canvas. This allowed us to use the familiar caption/alt fields from image cards and to let the feature image feel more connected to the post's contents and part of the editing workflow.
---
- removed `featureImageMeta` labs flag
no issue
- the bottom nav bar sits on top of the side bar which meant you weren't able to scroll down far enough to access the bottom of the side bar
- added extra padding to the side bar when the mobile nav is displayed so bottom settings of the side nav sit above the bottom nav bar
closes https://github.com/TryGhost/Team/issues/837
We previously added automatic retries to the editor controller for post saves; reviewing the resulting logs in Sentry we can see this stopped the "Server unreachable" error alerts showing to users because the requests typically succeeded on the first retry that was made 5 seconds later. However the problem is not limited to post saves and we can see other requests hitting the same issue, including when working in the editor such as adding embed cards, uploading images, or fetching member counts before publishing.
All of the API network requests we make in Admin run through an `ajax` service that makes and handles the request/response. By moving the retry logic for specific errors out of the editor controller and into the ajax service we can make temporary connection handling more graceful across the app.
- move retry behaviour from the editor controller to the `ajax` service so we can retry any request rather than just post save requests
- speed up retries so we reconnect as soon as possible
- first retry at 500ms, then every 1000ms (previous was every 5s which meant overly long waits)
- reduce total retry time from >30s to 15s
- improve reporting to Sentry
- report when a retry was required
- report when a retry failed
- include the total time taken for both success and failure reports
- include the `server` header value from requests to distinguish between CDNs
- include type of error so we can distinguish "server unreachable" from "maintenance" retries
no issue
- looks like we had an accidental merge of labs files and CSS back in after it was moved out of labs
- fixes odd font sizes in the settings modal
refs https://github.com/TryGhost/Team/issues/838
- fixed reordering not saving
- fixed last benefit item not saving without plus
- fixed cancel not removing unsaved benefits
- fixed dark mode product card color bug
- fixed no. of benefits counter on product card
- removed "Available in Portal" badge (all products are available)
refs https://github.com/TryGhost/Team/issues/825
With multiple products, it's possible to link to any products from themes.
- updates links area in Portal to be able to handle multiple products
- the new product selector for links is behind the alpha flag
refs https://github.com/TryGhost/Team/issues/836
refs ceb16b5e9f
Problem:
- `<GhImageUploaderWithPreview>` was updated to swap deprecated `{{action}}` usage to `{{on "click"}}` but that came with a missed behaviour change because the click event will now be passed as the argument to `@remove`
- the `<GhImageUploaderWithPreview>` usage on the general settings screen for social images had a syntax error in it's usage of the `mut` helper that meant the supplied argument was being used as the value rather than a forced `""` value. Result was that we were replacing the image urls with a text representation of the click event when attempting to remove images, leaving a broken image in place and no way to upload a new image
Fix:
- fixed incorrect `mut` usage to correctly force `""` as the value when removing social icons
- updated `<GhImageUploaderWithPreview>` to force `""` as the argument passed to `@remove` to avoid any other issues due to the behaviour change
refs TryGhost/Team#765
refs ccd917ff8c
This includes the changes to `@tryghost/members-csv` so that we can read
and write the `product` column from/to csv files. Allowing us to include
products in exports, as well as use them in imports.
no issue
- Mailgun now also provides per-domain Sending API Keys which has caused some confusion because they will allow sending emails but won't allow for analytics to be fetched unlike the Private API Key
refs a6c6def7e1
- we weren't checking if an error was a validation error by examining the number of errors on the post model, this meant we weren't falling through to the generic error handling/display logic that shows an alert for validation errors when a save isn't a background/silent save
no issue
- when Ghost is in maintenance mode after an upgrade we know it will come back shortly so automatically retrying the save in the same way we do for "server unreachable" errors provides a smoother experience compared to halting and showing a red alert bar
no issue
- post status was not being reset after certain types of failure to publish/unpublish/schedule which meant that the editor could be left in an odd in-between state where the displayed status did not reflect reality
- fixed "saving/publish/schedule failed:" wording in error message when a server unreachable error was detected, the "saving/publish/schedule" did not reflect the actual status change because we were passing through only the current status rather than previous+new status'
no issue
- if a ServerUnreachable error is triggered by a non-background-save then we'd show the expected custom alert and then immediately overwrite it because `savePost`'s catch was not expecting an `undefined` error
