refs https://github.com/TryGhost/Team/issues/1210
- when rendered, show button as greyed out if either text or url is missing
- show "Add button URL" in tooltip if the url is missing
- show "Add button text" in button if the text is missing
- adds wrapper element so the tooltip is not greyed out
refs https://github.com/TryGhost/Team/issues/1205
- Stored in the payload as an hexadecimal (or variable) value
- chosen with a dropdown through a pre-selected list of colors (or the publication accent color)
refs https://github.com/TryGhost/Team/issues/1205
- Uses the KoenigSettingsPanel to display a toggle
- The Emoji is set to an empty string when disabled
- And arbitrarily set to 💡 by default when toggled back on
no issue
The logic for "delete if empty" was duplicated in two places:
1. when `createComponentCard` is used to register a card, this option method was used when cleaning up a post when first rendering (cards in empty state can be saved before the editor auto-removes them but we don't want to show them again)
2. inside of card's own delete-if-empty handling on certain actions such as deselection or leaving edit mode
- added an `ifEmpty` property to each card component
- used by the editor's first-render cleanup routing if the property is present
- can be re-used internally for the card's own deselect/exit-edit-mode behaviour
- updated the cleanup routine in `<KoenigEditor>`
- added a `allComponentCardsRegistered` property that will return `true` when the `.component` property is set on every card (the property is set during card component initialisation so we're at the mercy of Ember's render process so not all card components will be immediately registered)
- swapped `_cleanup` for `_cleanupTask` that will wait for `allComponentCardsRegistered` to be `true` before performing cleanup, ensuring that we always have access to the card component's `isEmpty` property even when Ember renders cards across multiple render batches
- checks for `isEmpty` being a boolean and will delete the card if it's value is `true`
- updated all cards that had delete-if-empty behaviour
- added `isEmpty` properties
- removed duplicated logic in the `createComponentCard` calls
refs https://github.com/TryGhost/Team/issues/1164
- removed conditional logic for links on settings index now that the old theme settings routes do not exist
- updated error handling test to use new design settings screens
- modified templates' test attributes to work with new design
- fixed `enableLabsFlag()` test helper error when fixtures have already been loaded
no refs
- access to membership settings is restricted to owners and admins as contributors/authors cannot perform any actions on the page
- redirects non owners/admins back to site when trying to access membership settings via URL
refs https://github.com/TryGhost/Team/issues/1164
- the dashboard was still linking to the old theme setting routes but those have now been disabled to allow for the theme install redirect route to live in the same place
- removed the old links as they are scheduled for removal as part of the `customThemeSettings` labs flag cleanup anyway
no issue
The marketplace still uses the `/settings/theme/install` route but that was removed as part of the redesign for design settings.
- added `settings.design.change-theme.install` route that uses the newer theme install modal
- requires backing controller for query param support despite no template being rendered
- uses the `change-theme` controller's official theme list to fetch theme details based on query param `ref`
- added `settings.change-theme` route that lives on the old `/settings/theme/install` path and redirects to the new install route
- commented out the old theme settings routes ready for full cleanup/removal
no issue
- if the automatic private site login fails during post-auth setup, don't fully error because that will block Admin from loading properly
- the automatic login is a nice-to-have and making it look like it worked won't break anything that wouldn't already be broken when the browser is blocking x-domain requests
refs https://github.com/TryGhost/Team/issues/609
There's a 3 second timeout before a background save is triggered after the last edit, if the preview modal is opened in that timeframe it would show outdated content.
- added a task that is triggered when the preview modal is opened
- if a save task is already running it will wait for it to finish
- otherwise if the post is a draft and the editor has dirty attributes it will trigger a save
- modal shows a loading spinner whilst waiting for the save to finish so the preview contents always match the latest editor changes
no issue
- when switching from the user-specific `feature.launchComplete` flag to the global `settings.editorIsLaunchComplete` there was a missed replacement of `feature`->`settings` in the dashboard logic for showing the members activity feed
no issue
- updating the preview is done asynchronously in the background as it's not essential to the theme activation process being complete, however it was kicked off before we had waited for the custom theme settings to be re-fetched from the API. The front-end _has_ successfully swapped themes and settings at this point but when we preview we send a full set of custom settings meaning we were sending settings for the previous theme rather than the current theme because the local settings cache in Admin hadn't finished updating
refs https://github.com/TryGhost/Team/issues/1208
- removing the click event listener in the same event loop as the `dragEnd` event is triggered meant Chrome still allowed the `click` event to trigger causing the card to become deselected and the movable panel closed when a drag ends outside of the central editor canvas
- adding a 1ms timeout means the event loop where the dragEnd is triggered fully completes before the next tick begins where the click handler is finally removed
closes https://github.com/TryGhost/Team/issues/1208
- clear and disable selection when drag starts
- ensure click-cancel event handler is removed when destroying (FF could trigger destroy without triggering drag end leaving you with nothing clickable)
no issue
- if the automatic private site login fails during post-auth setup, don't fully error because that will block Admin from loading properly
- the automatic login is a nice-to-have and making it look like it worked won't break anything that wouldn't already be broken when the browser is blocking x-domain requests
refs https://github.com/TryGhost/Team/issues/609
There's a 3 second timeout before a background save is triggered after the last edit, if the preview modal is opened in that timeframe it would show outdated content.
- added a task that is triggered when the preview modal is opened
- if a save task is already running it will wait for it to finish
- otherwise if the post is a draft and the editor has dirty attributes it will trigger a save
- modal shows a loading spinner whilst waiting for the save to finish so the preview contents always match the latest editor changes
no issue
- when switching from the user-specific `feature.launchComplete` flag to the global `settings.editorIsLaunchComplete` there was a missed replacement of `feature`->`settings` in the dashboard logic for showing "start creating content" CTA, resulting in it being always shown
- removes `launchComplete` feature flag setup on user which was used earlier for launch complete behavior
no issue
- when switching from the user-specific `feature.launchComplete` flag to the global `settings.editorIsLaunchComplete` there was a missed replacement of `feature`->`settings` in the dashboard logic for showing the members activity feed
refs https://github.com/TryGhost/Team/issues/1121
- adds error reporting for `notifications.showAlert()` in addition to `notifications.showAPIError()` because the former is used for some handled errors but will still show the undesired red error bar
- adds `shown_to_user` tag to all reported errors. Only errors that result in the red error bar will be reported with the tag as `true`, there may still be cases where we display errors outside of the red error bar but those wouldn't make it to Sentry either, we'll need a full audit of Admin source to find those situations and handle the reporting manually
- adds `ghost` context to errors that are shown in the red bar
- `ghost_error_code` - code returned from the API or passed manually through the `notifications.showAPIError()` options argument. Will be filled in once the error message has been audited+approved
- `displayed_message` - the full error message displayed to the user. Admin combines multiple attributes from the error details so it's useful to see what we actually show
- `full_error` - the actual API error response or a client-side generated error object
- `source` - whether the red bar came from `.showAlert()` or `.showAPIError()`, useful for tracking down where errors originated
no issue
- updating the preview is done asynchronously in the background as it's not essential to the theme activation process being complete, however it was kicked off before we had waited for the custom theme settings to be re-fetched from the API. The front-end _has_ successfully swapped themes and settings at this point but when we preview we send a full set of custom settings meaning we were sending settings for the previous theme rather than the current theme because the local settings cache in Admin hadn't finished updating
