refs https://github.com/TryGhost/Team/issues/1130
- added `ui.contextualNavMenu` property that when set will switch the main nav menu between components, if it's not set then it will show the default "main" menu component
- added `design` menu sub-component of `gh-nav-menu` ready for use via `contextualNavMenu`
- moved sidebar contents from the design modal into this component
- updated design route to set/reset `ui.contextualNavMenu` to `design` on entering/leaving the route
- all other design routes are sub-routes so this works across all other design screens
- moved base design modal preview into the `settings/design/index` controller/template
- using index means that it's the default screen for `/settings/design` but will be automatically replaced by any other `design.x` routes
- moved `design/advanced` modal content into the `settings.design.advanced` controller/template and removed the modal handling from the route
refs https://github.com/TryGhost/Team/issues/1111
Extracted functionality for listing, downloading, activating, and deleting from the theme controller/template into separate components and services so that they are more composable/reusable in different situations.
- moved theme activation to a new `theme-management` service that uses the `modals` service to open the theme warnings modal or limits upgrade modal as required
- the activate process is a task so that consumers can store a reference to the task instance and cancel it to close any related warning/limit modals (eg, when navigating away from the route or closing the modal that kicked off the process)
- created new-pattern modals for custom theme limit upgrade, theme errors, and delete confirmation so that we can treat them as promises and close where needed from parent
- duplicated theme table component as `<GhThemeTableLabs>` with an actions redesign and a refactor to handle download, activation, and deletion itself making use of the new theme-management service and modals
- fixed some oddities with design modal's transition/modal close handling by simplifying the async behaviour and being more explicit
- added advanced design modal that contains the new theme table component and linked to it from footer of design modal's sidebar
refs https://github.com/TryGhost/Team/issues/559
When modals are re-used across the app it's annoying to have to remember the class names that it uses in every location it's used.
- added a `DEFAULT_MODAL_OPTIONS` object to the modals service that's keyed on the modal to be opened and contains any options that are repeated across every instance
- overrode the `modals.open()` method to merge in the default options before calling `super()`
- updated invocation points of shared modals to remove duplicated class name options
refs https://github.com/TryGhost/Team/issues/1111
- added override of the `ember-promise-modals` container component so that it doesn't render the background element when `omitBackground` is passed as an option when opening the modal
- fixes the flicker by not having a dark background transition in whilst the white overlay modal is also transitioning in from transparent->opaque
refs https://github.com/TryGhost/Team/issues/1111
refs https://github.com/TryGhost/Team/issues/1103
- moved customize modal from a link on the design screen to the main design screen
- changed modal design to be a full-screen overlay with side bar that emulates standard Admin design
- added toggled groups of settings in sidebar
- added `{{set-has}}` helper for use in conditionals matching when a Set contains an object
- added grouping of theme settings
- dropped unfinished advanced/change theme modals
no issue
Updated settings navigation to a completely redesigned flow for Ghost 4.0 🎉
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
Co-authored-by: Fabien O'Carroll <fabien@allou.is>
Co-authored-by: Rish <zrishabhgarg@gmail.com>
no issue
We weren't correctly clearing state for the "display modal" booleans when leaving screens. This meant that it was possible to end up in a state where where every time you access a screen you get the unsaved changes modal
no issue
- moved `document-title` Route extension's functionality into the `ui` service
- updates the title each time the router service emits a route changed event
- `ui.updateDocumentTitle()` can now be called directly from components rather than the confusing `this.send('updateDocumentTitle')` bubbling behaviour
- refactored the `titleToken` implementation to use the now-formalised `RouteInfo`'s `metadata` field (https://github.com/emberjs/rfcs/blob/master/text/0398-RouteInfo-Metadata.md#appendix-a)
no issue
- many routes were attaching classes to the `<body>` tag via the `StyleBody` mixin but those classes were never used and applied inconsistently throughout the app
no issue
- ran [es5-getter-ember-codemod](https://github.com/rondale-sc/es5-getter-ember-codemod)
- [es5 getters RFC](https://github.com/emberjs/rfcs/blob/master/text/0281-es5-getters.md)
- updates the majority of `object.get('property')` with `object.property` with exceptions:
- `.get('nested.property')` - it's not possible to determine if this is relying on "safe" path chaining for when `nested` doesn't exist
- `.get('config.x')` and `.get('settings.x')` - both our `config` and `settings` services are proxy objects which do not support es5 getters
- this PR is not exhaustive, there are still a number of places where `.get('service.foo')` and similar could be replaced but it gets us a long way there in a quick and automated fashion
closesTryGhost/Ghost#9119, refs TryGhost/Ghost#8483
- Apps - AMP
- Added `leave-settings-modal` component to Settings - Apps - AMP
- Apps - Slack
- Added `leave-settings-modal` component to Settings - Apps - Slack
- Added a `triggerDirtyState` action that will uses a new Array with the input data to trigger the dirty state on the parent settings model
- Apps - Unsplash
- Added `leave-settings-modal` component to Settings - Apps - Unsplash
- Used manual tracking of changes with using a custom `dirtyAttributes` property and a `rollbackValue` to manually rollback the `isActive` attribute on the model
- Code injection
- Added `leave-settings-modal` component to Settings - Code injection
- Design
- Added `leave-settings-modal` component to Settings - Design (only for navigation model)
- Used manual tracking of changes with using a custom `dirtyAttributes`
- Added an additional `updateLabel` action to underlying `gh-navitem` component which gets fired on the `focusOut` event, to detect changes on the label
- Team - User
- Added `leave-settings-modal` component to Team - User
- Used manual tracking of changes with using a custom `dirtyAttributes` to track changes in slug and role properties
no issue
Automated tools, code generators, and editor integrations are increasingly standardising on the import style used in `ember-modules-codemod`. Our import style differed a little with regards to service/controller injection imports which meant we were starting to see inconsistent naming.
no issue
- add eslint-plugin-ember, configure no-old-shims rule
- run `eslint --fix` on `app`, `lib`, `mirage`, and `tests` to move imports to the new module imports
- further cleanup of Ember globals usage
- remove event-dispatcher initializer now that `canDispatchToEventManager` is deprecated
no issue
- adds `eslint-plugin-sort-imports-es6-autofix` dependency
- implements ESLint's base `sort-imports` rule but has a distinction in that `import {foo} from 'bar';` is considered `multiple` rather than `single`
- fixes ESLint's autofix behaviour so `eslint --fix` will actually fix the sort order
- updates all unordered import rules by using `eslint --fix`
With the increased number of `import` statements since Ember+ecosystem started moving towards es6 modules I've found it frustrating at times trying to search through randomly ordered import statements. Recently I've been sorting imports manually when I've added new code or touched old code so I thought I'd add an ESLint rule to codify it.
no issue
- adds `settings` service that acts as a proxy to the singular settings model with methods to fetch and reload, also prevents accidentally loading only some settings types which has caused problems in the past
- updates app boot, signin, and signup processes to fetch settings ensuring that any part of the app can grab settings synchronously if needed
- removes `timeZone` service, it's no longer needed as we can grab `settings.activeTimezone` directly
- replaces all store queries for the settings model with appropriate `settings` methods
- refactors `apps/*` routes/controllers, they had become a little convoluted with the way they were dealing with settings and the new service helped to clean that up
requires https://github.com/TryGhost/Ghost/pull/8093
- adds `theme.activate()` method and associated adapter method for activating themes rather than relying on `settings.activeTheme`
- minor refactors to the `modals/upload-theme` component to use a full theme model
