refs https://github.com/TryGhost/Team/issues/559
refs https://github.com/TryGhost/Team/issues/1277
- switched modal implementation to the newer promise-modal style
- added `<GhEmailPreviewLink>` component that renders a link that when clicked opens the modal
- removes the need for templates/controllers to manually handle modal opening/closing and to pass actions down from parents
- updated all places we were triggering an email preview modal to use `<GhEmailPreviewLink>`
refs https://github.com/TryGhost/Team/issues/1277
- added `member` query param that expects a member ID
- using an ID as it makes the filtering simpler than using an email because there is no async member fetching required
- updated `filter` generation to build `type` and `member` parts and combine them in an AND query
- updated link in member screen to use a `member` param rather than a `filter` param
- resets any `excludedEvents` param so all events for the member will be shown when following link from member->members-activity
refs https://github.com/TryGhost/Team/issues/1277
- moved event parsing from a component to a helper
- keeps code as a plain function
- allows for per-event parsing which helps with rendering as we're not rebuilding/re-rendering a whole array each time the events data changes when a new page is loaded
- updated to include full member and email objects (will be used later for email preview popup)
- updated members-activity table row component to use the event parser helper for better event details
refs https://github.com/TryGhost/Team/issues/1290
- added an explicit `current-when="members-activity"` so the active class is not tied to the default behaviour of matching specific query params
refs https://github.com/TryGhost/Team/issues/1290
- changed query param from `filter` to `excludedEvents`
- exposing filter directly creates problems converting back to NQL after parsing+modifying the query
- removes suggestion that raw NQL can be manipulated by editing the URL
- allows us to use a set of well-defined query params to build the underlying filter string from scratch each time a query param changes
- added `<MemberActivity::EventTypeFilter>` that renders a filter button with a dropdown containing a checkbox for each event type
- if no `member` property is set on the members-activity controller (soon to be another query param) any email event types are hidden because the API can't currently paginate those correctly and in any case they would drown out any other type of event
refs https://github.com/TryGhost/Team/issues/1277
- re-uses same fetcher resource used on member activities screen
- allows for component to be simplified as it no longer needs to care about handling data loading itself
- drops use of 1-minute data caching as there is no real need for it in typical usage and can be confusing when the dashboard didn't update as expected
- exposed error message on `members-event-fetcher` if one is encountered
refs https://github.com/TryGhost/Team/issues/1277
- added `ember-could-get-used-to-this` dependency to get access to Resources
- context: https://www.pzuraq.com/introducing-use/
- added MembersEventFetcher resource for loading members events
- using a Resource allows for a better data loading experience using only components
- uses raw data from the API rather than going through Ember Data because we don't need full models or session-length caching that gives us
- data is kept around in memory for the lifecycle of the resource, if the `filter` param changes the resource is torn down and recreated so it starts from page 1 again, once it's no longer used by a component it's torn down so data isn't kept around
- paginates by using a `created_at:<={lastSeenTimestamp}` filter - this assumes the API can handle that effectively as a cursor with no duplicate or skipped records
- updated `members-activity` template to use the new resource and control data loading using infinite scroll
- moved overall screen structure from the `<MembersActivity::Table>` component into the `members-activity` template so that the table component can stay focused on just the table display
no issue
- bumped `ember-source`, `ember-data`, and `ember-cli` to latest 3.22.x versions
- fixed errors caused by updating properties inside of a render
- `<GhPublishMenu>` removed insta-call of `@setSaveType` when rendering sub-components in favour of pre-setting the default `@saveType` value when the underlying post status changes
- updated `<GhNavMenu>` to use the run-loop to update the `firstRender` property once rendering has finished rather than mid-render
no issue
- part of ember upgrades
- removed all unnecessary usage of `.get`
- cleaned up imports where we had imports from the same module across multiple lines
- standardized on importing specific computed helpers rather than using `computed.foo`
- switched tests from using `wait()` to `settled()`
refs https://github.com/TryGhost/Team/issues/1277
- if email events were passed through the parser they had blank actions and objects
- added `opened`, `received`, and `failed to receive` actions for email events
- changed object to equal `an email` for any email events
refs https://github.com/TryGhost/Team/issues/1277
- `data-cache` service has a `.set(key, data, lifetime)` method that will store the data under the key and sets a timeout that will remove the data when the lifetime expires
- data can be retrieved with `.get(key)`
- allows for components to cache data for use when re-rendering without having to worry about keeping track of their state and it's expiration manually somewhere else
- moved caching concern out of the `members-activity` service and into the latest-member-activity dashboard component which is the one that cares about it's data and cache lifetime
- frees the `members-activity` service up to be more generic as it's no longer tied to the dashboard component's concerns
- component switched to using a task rather than a promise so it is automatically cancelled if it's destroyed before data fetching is complete
no issue
- we want to re-use this component as display-only on the email newsletter settings screen but the previous component design meant that changes to the `@filter` argument did not update the display
- moved to using getters for the internal base/specific filter Set instances so they are auto-updated when the `args.filter` param changes
- updated the `toggleSpecificFilter` action to store the current specific filter as temporary internal state when toggled off so it can be re-filled when toggling back on
- this interaction was why the component state had previously been disconnected from the `@filter` param
- moved filter string generation into an explicit `updateFilter` method that is called when any action occurs that should update the filter string. Changes to the filters are passed in as arguments so that we call the passed in action which will then update the `@filter` argument and the component state can react accordingly
refs https://github.com/TryGhost/Team/issues/1277
- renamed `<GhActivityTimeline>` to `<GhMemberActivityEventParser>` and modified so that it yields parsed events rather than directly renders them
- makes the component re-usable as it can be used to decorate raw events ready for use in context-specific templates
- switches to using a getter to yield the parsed events so that they will update automatically when the `@events` argument changes
- updated `<Dashboard::LatestMemberActivity>` to use `<GhMemberActivityEventParser>` and keep the member activity box output local to itself
- added integration tests for `<Dashboard::LatestMemberActivity>`
- added Mirage setup for member activity event models/serializers/route
refs https://github.com/TryGhost/Team/issues/1277
- first step of further refactoring to make member activity display more generic
- separates component data loading from overall controller logic and allows it to be tested in integration tests as well as acceptance tests
refs https://github.com/TryGhost/Team/issues/1277
- added `/members-activity` route with associated controller, template, and components behind labs flag
- table component currently renders some dummy rows
- added navigation item to main menu
- will use the currently set `?filter` query param unless clicked whilst already on the `/members-activity` screen in which case it will reset the query
- added link to dashboard members activity panel
- added link to member details activity panel
- sets the filter param to `?filter=member:{member.id}` in preparation for the feed to be filtered to the member's activity
- updated the labs-flag test helper file to export both `enableLabsFlag()` and the new `disableLabsFlag()` so it's easier to test for flag-disabled functionality
no issue
- the branding modal was a hangover from before the design settings screen that hadn't been fully removed after the newer settings screen was released
refs https://github.com/TryGhost/Team/issues/559
- switched to new ember-promise-modals pattern
- removed controller and template in favor of opening modals directly from the route
- removed unused `mousedown` event handlers - they are only necessary when an input blur would trigger validation errors
- fixed Enter key not triggering create action by adding an `{{on-key "Enter"}}` event handler to the name input
- fixed scroll not resetting to top of integrations screens when navigating between them by adding `{{scroll-top}}` element modifier to the main content sections
refs https://github.com/TryGhost/Team/issues/559
- switched to new ember-promise-modals pattern
- simplified `willTransition` handling because we can now wait on the promise returned from opening the modal
- the modal content was changed to use `{{on "click" (fn @close true)}}` on the "leave" button so we can check for that return value for leave confirmation
refs https://github.com/TryGhost/Team/issues/559
- changed modal to use new modal pattern
- fixes padding jump when opening due to improved animation behaviour not using duplicated elements
no issue
- offer-related modals were split across the top-level `modals` directory and the `modals/offers` directory
- normalized to the `modals/offers` directory
no issue
- converted component to glimmer component and native class syntax
- reduced duplication by adding a description of each searchable model that is then used for data loading and searching
- removed convoluted use of computed properties as they weren't needed - the result of the search function is used by `<PowerSelect>` directly so we don't need any tracking/automated re-rendering
refs https://github.com/TryGhost/Admin/pull/2041
- the pretender upgrade highlighted an issue with the component's progress event handler where it could fire and attempt to set the progress property after the component has been destroyed
no issue
- after clicking the "Publish and send" button in the publish confirmation modal the post is saved and an email is created which caused the wording to change to automatically switch to the "publish only" state because posts with existing emails can't be sent again
- changed the wording-choice data to be set statically based on data available when the modal is triggered rather than auto-updated based on overall system state
refs https://github.com/TryGhost/Team/issues/1164
- removed flag and labs screen toggle
- removed all conditionals
- removed all old/unused route/controller/component files
- renamed labs components and classes to non-labs naming
no-issue
If the onUploadStart or onUploadSuccess methods error, and the error
does not contain a payload property then we recieve an opaque error
message which can be difficult to understand.
no-issue
Currently the onUploadSuccess and onUploadFailure have no way to
identify which upload has succeeded or failed other than the filename.
However the filename is not guaranteed to be unqiue, so this can cause
bugs.
no issue
- the upgrade button is a link rather than a button so was not triggering the modal's close behaviour
- added an `{{on "click" @close}}` handler to the link. `@close` does not preventDefault so the link's transition will still occur
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/1001
Our email newsletter preview is rendered inside of an iframe with
javascript disabled. When opening links from the preview, the new
window/tab inherits this property - which breaks links to twitter.
refs https://github.com/TryGhost/Team/issues/1169
We want all publish actions to trigger a confirmation modal. Currently that confirmation modal is controlled by `<GhPublishmenu>` which made it difficult to use from the route-induced publish shortcut.
- removed old shortcut mixin approach from the editor route
- added modern keyboard handler to a hidden element that is rendered any time the publish menu is present
no refs
By default, the uploader component was always using the `post` method to make upload calls for the files. Since some usecases like uploading media thumbnails need a different request method like `put`, this change allows overriding the request method used in upload.
refs https://github.com/TryGhost/Team/issues/1225
- iterations of earlier approaches (modal-image-selector, and kg-media-selector) for the gif selector were kept around whilst we narrowed down the interaction patterns, we've settled on the inline-image-selector pattern introduced in 3f3b66b668 meaning the others are no longer needed
no issue
- fixed typo in the install-theme modal that meant we weren't correctly identifying Casper as the default theme meaning an attempt to install it was made instead of activating it
refs https://github.com/TryGhost/Team/issues/1121
Double-clicking the delete button in the confirmation modal could trigger a second attempt to delete the post/page when it had already been deleted resulting in an ugly/incomprehensible error bubbling up.
- added `{drop:true}` to the task instance so it can't be called again whilst it's currently running
- added a guard for `isDeleted` so we don't attempt to destroy an already deleted record
- added a `true` return so the button indicates a successful state rather than an error state whilst the modal is closing
