Enables splitting of multiple newsletters backend and ability to add newsletters behind different flags. This allows release and testing of all the new backend behavior for multiple newsletters to work with the default newsletter, and later allow sites to create multiple newsletters.
no issue
- depending on when the newsletter settings route is accessed we would sometimes show an empty newsletter list
- the problem stems from the use of a non-reactive fixed list of displayed newsletters where we manually update the list when we know the list should change. On initial load we were using `await store.findAll('newsletter')` then updating the displayed list, however the default behaviour for `store.findAll()` is to immediately return a live array - this doesn't work for our use-case because we'd then potentially update our displayed list from incomplete data
- added the `{reload: true}` option to the `findAll()` call to force a wait for the API request to finish before updating the displayed list of newsletters
closes https://github.com/TryGhost/Team/issues/1530
- added confirmation modal that uses passed in archive task when confirming to provide feedback on progress
- switched archive link from immediately triggering the archive task to an action that launches the confirm modal
no issue
When multiple newsletters existed, the actions dropdown menus were all rendered on top of each other but hidden with CSS. This resulted in clicks that you expected to open an actions menu immediately triggering actions on a newsletter higher up in the list.
- switched from `<GhDropdown>` to `<GhBasicDropdown>` which adds/removes the dropdown content elements rather than rendering everything and hiding with CSS
- updated styling to match previous implementation
- added `.anim-fade-in-scale` classes for use with `{{css-transition}}` so we can keep the open/close animation
- `ember-basic-dropdown` does have support for transitioning in/out CSS classes but they are only triggered on the first open/close for each menu which resulted in oddly inconsistent behaviour with multiple menus in a list
- close animation doesn't actually work because the outer elements are removed by `ember-basic-dropdown` preventing `css-transitions` from performing it's animation
refs https://github.com/TryGhost/Team/issues/1513
- `sender_name` is now nullable with a fallback to the site title
- updated new-newsletter route
- removed default setting of site title in `senderName` of the new newsletter instance
- removed extra checks when showing unsaved changes modal as we no longer need to compare the `senderName` attribute against the site title
- updated newsletter preview so the sender name falls back to the site title
- updated sender name input placeholder to show the site title
- removed not-empty validation
- fixed the switch to "multiple newsletter" state in the background of the new-newsletter modal
- problem was `displayingDefault` getter was looking at all active newsletters rather than just the filtered ones so it was counting the new-but-unsaved newsletter even though it wasn't displayed in the list
- fixes layout glitch when the new-newsletter modal animates out after cancelling creation
no issue
- when displaying only the default newsletter there's no option to drag/re-order but the border was still moving on hover as it does when displaying the drag handle
- updated the class name to take `displayingDefault` into account when adding the draggable class
closes https://github.com/TryGhost/Team/issues/1483
- updated newsletters list to use `<SortableObjects>` and `<DraggableObject>`
- swapped the `filteredNewsletters` reactive getter for a tracked property because `<SortableObjects>` replaces the value with a new array when re-ordering which isn't compatible with a getter
- required explicit update of the list any time the list should change through filter swap, archive, unarchive
- required explicit update of the list via router event when leaving the "new newsletter" route so any newly added newsletter can be displayed
- added action for handling update of `sort_order` properties when a re-order occurs
- updates every newsletter setting `sort_order` of the active newsletters first based on the new order, followed by all archived newsletters following their existing order
- disabled sorting of newsletters in the archived newsletters list
- hides the grab handle and disables the resize on hover
- allowing re-order of archived newsletters would complicate the re-order+save algorithm and re-ordering archived newsletters doesn't have a use-case
closes https://github.com/TryGhost/Team/issues/1476
- added dropdown for switching between active and archived newsletters
- modified the "default" newsletter display so it's only activated when a single active newsletter is shown
- added ability to un-archive a newsletter with a switch between "archive" and "un-archive" actions based on newsletter status
- if all archived newsletters are un-archived, automatically switches to "active" filter so you're not left with an empty list
refs https://github.com/TryGhost/Team/issues/1441
- switched "leave settings" confirmation modal on members email settings screen over to modern modal pattern
- removed unused `showEmailDesignSettings` property and `closeEmailDesignSettings()` action on `<Settings::MembersEmailLabs>` component
- the used property and action live on the controller, looks like it was a copy/paste hangover when functionality was moved to a component
- added newsletter model
- includes design-related attributes which are not yet supported by the API but are due to be added
- includes `default` attribute but there is no setting for it, due to be removed from the API but it's needed for save not to error for now
- set up basic mirage model and endpoints
- added validation for main settings to match API validation
- added `EditNewsletter` modal
- separate tabs for general newsletter settings and design-related settings
- used for both creating and editing newsletters
- added `/settings/members-email/newsletters/new` and `/settings/members-email/newsletters/:id` routes
- both display the `EditNewsletter` modal on top of the members-email settings screen with the appropriate newsletter model
- updated `<Settings::MembersEmailLabs::NewsletterManagement>` component to work with real newsletter model instances and the new add/edit routes
- removed now-unused `newsletter` service that was providing mocked data for earlier design iteration
refs https://github.com/TryGhost/Team/issues/1441
- pulls newsletter-related functionality into one place to keep higher-level components from knowing about too many concepts and becoming bloated
- updated temporary newsletters service to have fully tracked objects so the `active/archivedNewsletters` properties can be closer to how they will work with full models
