issue https://github.com/TryGhost/Team/issues/857
- The goal is to avoid testing for the owner role only is cases where we should be testing for the owner or admin role
- `isOwner` => `isOwnerOnly`
- `isAdmin` => `isAdminOnly`
- `isOwnerOrAdmin` => `isAdmin` (concerns now both Owner and Admins)
no issue
- converted publish menu and `gh-tags-list-item` components to glimmer syntax so data attributes can be passed in via `...attributes`
- added explicit `data-test-button` bound attribute to `gh-task-button` component
- moved `modal-theme-warnings` auto-bound data attribute from JS file to explicit html attribute in template
no issue
Having `session.user` return a promise made dealing with it in components difficult because you always had to remember it returned a promise rather than a model and had to handle the async behaviour. It also meant that you couldn't use any current user properties directly inside getters which made refactors to Glimmer/Octane idioms harder to reason about.
`session.user` was a cached computed property so it really made no sense for it to be a promise - it was loaded on first access and then always returned instantly but with a fulfilled promise rather than the underlying model.
Refactoring to a synchronous property that is loaded as part of the authentication flows (we load the current user to check that we're logged in - we may as well make use of that!) means one less thing to be aware of/remember and provides a nicer migration process to Glimmer components. As part of the refactor, the auth flows and pre-load of required data across other services was also simplified to make it easier to find and follow.
- refactored app setup and `session.user`
- added `session.populateUser()` that fetches a user model from the current user endpoint and sets it on `session.user`
- removed knowledge of app setup from the `cookie` authenticator and moved it into = `session.postAuthPreparation()`, this means we have the same post-authentication setup no matter which authenticator is used so we have more consistent behaviour in tests which don't use the `cookie` authenticator
- switched `session` service to native class syntax to get the expected `super()` behaviour
- updated `handleAuthentication()` so it populate's `session.user` and performs post-auth setup before transitioning (handles sign-in after app load)
- updated `application` route to remove duplicated knowledge of app preload behaviour that now lives in `session.postAuthPreparation()` (handles already-authed app load)
- removed out-of-date attempt at pre-loading data from setup controller as that's now handled automatically via `session.handleAuthentication`
- updated app code to not treat `session.user` as a promise
- predominant usage was router `beforeModel` hooks that transitioned users without valid permissions, this sets us up for an easier removal of the `current-user-settings` mixin in the future
- added max height to theme uploader modal container to avoid long list of errors leaning out of screen
- added shadow on top of footer to indicate long list of errors
refs https://github.com/TryGhost/Team/issues/779
- add "- Saved" to status text in editor when a post has no unsaved changes
- uses `savedIndicator` labs flag so we can test and tweak behaviour before go-live
no issue
- there can be cases where the connection fails but Ctrl/Cmd+S won't work as a direct retry (eg, publish fails so the status reverts, in that case Cmd+S would save a draft rather than re-attempt a publish)
- switched to a neutral "try again" message
no issue
- transitioning of all properties causes flickering when modals are animated in and out because the DOM elements are duplicated before fading out to account for Ember's component destruction
- applied same property transition list as used for `.gh-btn`
refs https://github.com/TryGhost/Team/issues/840
- added media queries so the image sizing doesn't take the sidebar width into account when it's acting as a popover rather than a sidebar
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
