refs https://github.com/TryGhost/Team/issues/1169
Previously we were only showing a confirmation dialog if a publish action would trigger an email which was inconsistent and did not instil confidence when publishing.
- replaced old `modal-confirm-email-send` modal with the newer-style `modals/editor/confirm-publish` component
- updated to handle standard publish in addition to email publish
- updated copy
- added "error" state when attempting to send email-only post to no members
- updated publish menu `save` task to open the confirm modal when going from `draft` to `published` or `scheduled`
- underlying save with email polling moved to `_saveTask` so it can be re-used across `save` task (when not publishing) and when confirming from the modal
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
refs https://github.com/TryGhost/Team/issues/1115
This removes all the usages of the Offers labs flag which do not modify routing.
The routing changes have been left for @peterzimon
closes https://github.com/TryGhost/Team/issues/1193
- there was a typo in the limits modal component name that is shown when the limits service check fails when opening the upload theme modal
- added acceptance test with associated fix of modal name test selector in the template
no issue
- moved navigation settings tests from old settings/design tests to a separate file and unskipped them
- added happy-path acceptance tests for
- rendering design screen
- installing an official theme from the themes list
- uploading a custom theme
refs 63b1e1d385
- test was using an old `/settings/design` route as something to navigate away to but the behaviour no longer matched the test expectations
- switched to using `/settings` as a more stable route
no-issue
This adds the ability to apply complex filters to members, as well as to
perform bulk actions on the filtered set, including unsubscribing,
adding & removing labels.
refs https://github.com/TryGhost/Team/issues/947
- Added a "distribution" dropdown component to the post publish menu allowing to select from one of three available types of distribution: publish, poblush&send, and send
closes https://github.com/TryGhost/Team/issues/950
- fixes the mrr value/chart on dashboard when a site has no new mrr events in more than 30 days shown as 0
- adds tests to cover more mrr event scenarios
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
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
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 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/771
- added `<GhEditorFeatureImage>` for more flexibility than offered by `<GhImageUploaderWithPreview>`
- updated to more closely match intended designs
- removed alt/caption support from `<GhImageUploaderWithPreview>` as it's no longer used
- fixed upload/delete/upload not working due to file input references getting out of sync
refs https://github.com/TryGhost/Team/issues/707
Placing focus in the title aligns better with typical editorial process.
- switched `autofocus` attribute from body to title for new posts
- added a default value to the `mobiledoc` attr on the Post model, without it the autosave when moving from title to editor creates a forced re-render and clears the focus whilst you're typing
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.
https://github.com/TryGhost/Team/issues/581
The API now supports `posts.visibility` being an NQL string as well as the special-case `'members'` and `'paid'` values so the post settings menu visibility select needs to be updated to reflect that.
- swapped visibility dropdown for two radio buttons, "Public" and "Members-only" which uses the `<GhMembersSegmentSelect>` component
- updated post model to use a `visibility-string` transform
- converts `members` and `paid` to/from the NQL equivalent for correct display in the segment select
- updated post model with two additional properties `isPublic` and `visibilitySegment`
- `isPublic` helps with the radio button display
- `visibilitySegment` allows fallback to the default content visibility setting when set to public
- added validation for `post.visibility` so we can show an error and skip saving when members-only is selected and the segment select is cleared
- deleted the now-unused `<GhPsmVisibilityInput>` component
refs e25e36352d
- referenced refactor accidentally removed direct usage of `params` in `fetchMembersTask()`
- because it's called from the `model()` hook the query param properties on `this` have not yet been updated to the new params meaning we were querying the API with stale params
refs https://github.com/TryGhost/Team/issues/585
requires https://github.com/TryGhost/Ghost/pull/12082
When a label or status filter is selected on the members screen show a "Delete selected" option in the actions dropdown. Bulk deleted members will _not_ have any subscription data modified in Stripe, if a member should be deleted and have their subscription cancelled it's necessary to do that on a per-member basis.
- updated bulk delete handling to match API
- added link to bulk delete confirmation modal in members actions dropdown (only shown when label, status, or search is used)
- updated testing framework for members
- added label factory for easier test setup
- updated `GET /members` and `DEL /members` endpoints to work with label filters
- updated test selectors for easier reference in tests
refs https://github.com/TryGhost/Team/issues/587
- This is first pass on the frontend limit-service integration. Max count queries are substituted with HTTP requests to mimick backend checks. Note, they are not meant to substitute backend checks only to suplment them.
refs https://github.com/TryGhost/Team/issues/572
- Replaced dropdown in invite-user modal with radio buttons
- Added description for each user role
- Added icon to provide more info on hover for each role
- Got rid of unused box styling
refs https://github.com/TryGhost/Team/issues/587
refs e30b9735fa
- It was not possible to invite a new Contributor to a site that has reached its limit
- This fix divides the resend invite action into two separate steps: 1. Deleting existing invite 2. Creating a new one for the same data
- It was hitting the limit because the permissions were correctly checking for "add" action being executed when the limit of invites/staff users was already used up. By removing existing invite we mimic the behavior the server would do for us anyway (2111992dd4/core/server/services/invites/invites.js (L18-L22))
Co-authored-by: Rish <zrishabhgarg@gmail.com>
no refs
MRR start date value for charts was being calculated with start value as 0, assuming we have the data for first date in our range to use as start value. Since the events data returned only has data on dates where any MRR event happened, in case the first date in our range didn't have any. data we started from 0 instead of value on previous date. This fix
- updates calculation to pick the start value for chart based on value on last date in our range(30 days)
- adds unit tests for stats
refs 10b48b1d6d
refs 1531712d92
- the tour feature is no longer used so all associated code can be removed
- removes `liquid-tether` dependency as it was only used by the tour throbbers/popovers
refs 0503ce5f35
- referenced commit changed `dashboard` to redirect to `site` when logged in user is not an owner or admin
- updated tests to reflect the change
