refs https://github.com/TryGhost/Team/issues/1141
Showing canceled subscriptions provide a more complete picture of the activity of a member.
- Given there is no `member.product` object when a subscription is canceled, use the `member.subscriptions.price.product` objects instead of `member.products`.
- applied boy-scout rule for linter errors and and code formatting
- removed `multipleTiers` flag conditionals as it's now GA
- set up subscriptions as a separate mirage resource so they are easier to work with
- updated `PUT /members/:id/` endpoint to match real API's complimentary subscription behaviour
- modified mirage member serializer to match API output
Co-authored-by: Kevin Ansfield <kevin@lookingsideways.co.uk>
Co-authored-by: Peter Zimon <peter.zimon@gmail.com>
no issue
- email open rate is shown by default so we don't need to add the column a second time when the list is filtered by that data
- added `email_open_rate` to the default columns list so it's ignored when adding any filtered-by columns
refs https://github.com/TryGhost/Team/issues/1423
- problem:
- all members requests were automatically adding `?include=email_recipients` as the email recipients relationship was set up to be always embedded
- embedded email_recipient records also embed the whole email record
- on the members index screen this meant for each of the 50 members loaded on a page we were also loading every email they have ever received resulting in a huge API response
- this was not a problem previously because the API was ignoring the `include` parameter on the browse endpoint and Admin wasn't formatting the include properly in snake_case
- solution:
- the only place we need associated email recipients is on the member details screen where they are used to show the email activity feed
- removing the `{embedded: 'always'}` option for the `member.emailRecipients` association stops `?include=email_recipients` being added automatically to every members request
- the member details screen explicitly adds `?include=email_recipients` so no further changes are needed
- activity feed will be changing to use proper event objects in the future and further optimisation can be made
refs https://github.com/TryGhost/Team/issues/1423
- problem:
- all members requests were automatically adding `?include=email_recipients` as the email recipients relationship was set up to be always embedded
- embedded email_recipient records also embed the whole email record
- on the members index screen this meant for each of the 50 members loaded on a page we were also loading every email they have ever received resulting in a huge API response
- this was not a problem previously because the API was ignoring the `include` parameter on the browse endpoint and Admin wasn't formatting the include properly in snake_case
- solution:
- the only place we need associated email recipients is on the member details screen where they are used to show the email activity feed
- removing the `{embedded: 'always'}` option for the `member.emailRecipients` association stops `?include=email_recipients` being added automatically to every members request
- the member details screen explicitly adds `?include=email_recipients` so no further changes are needed
- activity feed will be changing to use proper event objects in the future and further optimisation can be made
refs https://github.com/TryGhost/Team/issues/559
refs 054a5f15f5
- with the update of `ember-promise-modals` we started to get deprecation warnings when using `modals.open('modal-component-name')`
- upcoming Ember build updates will introduce tree shaking but using run-time lookup of modal components by name works against that because it's not statically analysable
- switched to importing components and passing the component class directly, eg. `modals.open(ModalComponent)`
- standardized modal component class names with a `MyModal` style to get better behaviour in code editors when it auto generates imports
- dropped the modal defaults from the modals service because we can now use a static `modalOptions` property on the modal components themselves when we want to override the defaults
no issue
- dropped `id` attribute added to `<GhBenefitItem>` because it was only using the index resulting in multiple `id="1"` on the page which is invalid HTML and caused Glimmer to complain
- added a check for `portalPreviewIframe` existence when the portal message listener in the offer controller is fired because it was occurring out of sync with the tests and throwing async errors that were picked up in random later tests
no issue
- we were missing handling for the view-theme modal being closed outside of a route transition meaning the URL would stay on `/settings/design/view-theme/Theme` even though it's the index that was shown, preventing the same theme being viewable again and back/forward behaving as expected
refs 054a5f15f5
- `beforeClose` behaviour has changed slightly with the upgraded ember-promise-modals
- added a guard for the modal existing when transitioning back to the integrations index screen, this makes sure we're not transitioning back to the index screen after the modal has already initiated a transition to the integration edit screen
closes https://github.com/TryGhost/Ghost/issues/14296
- bumped fork of `ember-promise-modals` as newer version exposes all focus-trap options and per-modal disabling
- disabled focus-trap for the post preview modal because it was preventing clicks on the input elements performing default behaviour
no issue
- removed the count task state from the `disableEmailOption` getter so it doesn't get used to show the "Add members" notification before the count request has finished
no issue
- fixed duplicate `id` attribute on the specific people checkbox
- switched toggle behaviour from a click event on the surrounding div to a change event on the checkbox
- the surrounding `<label>` has appropriate `for` attribute so it acts as the click-to-change target
- added `aria-label` attributes to the checkboxes because the label element we're using does not surround any content that labels the checkbox
closes https://github.com/TryGhost/Team/issues/1399
- the publish/schedule save type was not being reset when closing the publish menu, even though the underlying post publish date _was_ reset leading to the publish menu and the post state being out of sync
- added a reset of the save type when closing the menu, this means "schedule" will need to be re-selected when re-opening the menu but that follows the same behaviour as the reset of the publish menu options
refs 79afb5fc9c
refs 652fc883d7
- test was set up expecting "Label" to be the default filter shown when opening the members filter UI but it's been changed to "Name" which is no longer behind a labs flag
refs: https://github.com/TryGhost/Team/issues/1373
- Simplify the member details link on single member activity
- Adjust all the activity scrolling to work better at all sizes
- Make the header work properly with truncating at narrower viewports
- Remove unnecessary CSS and classes
- Remove the top line from the member detail box
- Move the member detail box so it stays when scrolling
- Make the empty state work with new member detail box position
- Better scrolling full width whilst not having full width like members
- Fix the subscriptions event icon which was a white box in dark mode
- Adjustments to global gh-list-scrolling styles at narrower viewports
- Test fully on narrower viewports and major browsers
https://github.com/TryGhost/Admin/pull/2286
- `session.authenticate()` returns from it's promise as soon as the authenticate request is completed but it was assumed that it returned after the `session.handleAuthentication()` promise was also completed. A side-effect of that was that depending on network timing, the setup flow could transition to the dashboard before we had loaded all of the necessary user, config, and settings requests
- normally that's not a problem because `handleAuthentication()` kicks off a transition once authentication is fully complete, in the setup flow we're handling the transition manually so need a way to manage the full async flow from outside of the session service
- it didn't show up as a problem previously because the setup flow transitioned to a third setup screen that didn't require all of the post-auth data to exist
- moved the async parts of `session.handleAuthentication()` into a task and updated to return the currently running task instance if one was already running
- lets code that is relying on the full authentication flow to have completed call `await this.session.handleAuthentication()` without causing a double-load of the post-auth API requests
- updated setup flow
- removed manual `session.populateUser()` call as that was a workaround for the async timing issue and caused a double-fetch of the current user API endpoint
- added an `await this.session.handleAuthentication()` call to the manual post-auth handler so we don't transition until the full auth flow is complete
refs: https://github.com/TryGhost/Team/issues/1373
- reduced from 10 to 5 to keep things visually simpler
- sneaked in a little colour tweak to link on activity member detail header
refs: https://github.com/TryGhost/Team/issues/1373
- nothing much here, just changing where the member detail header renders on activity
- added a little padding to empty states to better vertically center
refs: https://github.com/TryGhost/Team/issues/1373
- changed searched name clear to say Clear Member as there was duplicates across the screen
- tried to tidy up the Member Detail link when filtered by members in Activity
- few tiny CSS tweaks
refs https://github.com/TryGhost/Team/issues/1408
- "Name" is the first filter in the list and has a basic value type so it makes sense to make it the default compared to label
