no issue
If you scheduled a post to a specific newsletter it was no longer visible in the scheduled state of the publish menu making it difficult to know the behaviour when coming back to a scheduled post.
- duplicated the newsletter dropdown from the draft to the scheduled state components and disabled it the same as the other recipient options
- added temporary workaround for missing newsletter embed for the posts endpoint in the API
- adds `newsletterId` attribute to the post model
- uses `post.newsletterId` to find the matching newsletter model from the available newsletters list
closes https://github.com/TryGhost/Team/issues/1479
- updated post adapter to append `?newsletter_id=xyz` when passed a `newsletterId` adapterOption
- updated editor save task to pass `options.newsletterId` through as `adapterOptions.newsletterId`
- set up `post.newsletter` relationship ready for handling embedded newsletter association from the API
- explicitly deleted when serializing back to the API as it doesn't yet ignore the attribute
- updated `<GhPublishmenu>` for newsletter support
- fetches newsletters on first render so they are available in the dropdown
- sets "default" (first in the ordered list) newsletter as the initially selected newsletter
- adds newsletter dropdown to draft publish menu
- passes `newsletterId` option to editor save task when it's set
This is a minimal implementation for testing. Not included:
- correct free/paid member counts based on selected newsletter
- correct member count in confirmation modal
- indication of selected newsletter for scheduled post
closes https://github.com/TryGhost/Ghost/issues/14354
When setting/cleaning up the publish menu state we were incorrectly reverting to the default "publish & send" state when a post was already set to be email-only. This resulted in an unexpected and non-obvious switch to "publish & send" when re-scheduling a scheduled email-only post.
- updated the publish menu setup and cleanup routines to account for scheduled, email-only posts
- fixed the header in the publish menu to say "sent" rather than "published" when an email-only post is scheduled
no issue
- This will help with the octane migration and you can still run the lint rules even when they are todos. (Checkout the docs at 158b119667/docs/todos.md) The good news is any new code will be checked against the recommended config.
- I fixed all the auto fixable things we could get in this PR as well
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/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 issue
- fixes the "publish/send" dropdown showing when mail is not allowed by tying it to the `canSendEmail` property rather than always showing when editing a draft post
- was previously showing when mailgun is not configured and when default email recipients is set to "disabled", in both cases the recipient selection was never available so the dropdown was confusing and lead to invalid states
- removed the unnecessary property`showEmailOnlyInput` - replaced with `@canSendEmail`
- removed the unnecessary property `nextActionName` - it always resulted in "publish" because it was only being shown for pages and pages can't be sent by email
- removed the logic for setting the initial selected option in `<GhDistributionActionSelect>` because it meant the select was not directly tied to the real distribution action value leading to mixed states across components. Switched to using the passed in `@distributionAction` value directly.
- fixed the publish button incorrectly showing "Publish & send" when no send would be occurring for a post
- if "Publish & Send" is selected, the button will now show "Publish" when no recipients are selected
- fixed the publish button incorrectly showing "Publish & send" for pages
- fixed the now/schedule radio texts not changing when publish type was set to "Send" - the conditionals were incorrectly looking at `this.args.post.emailOnly` which is incorrect syntax would only update _after_ saving, switched to the menu's internal `@emailOnly` argument instead
closes https://github.com/TryGhost/Team/issues/1151
The publish-type state was being set directly on the model in the publish menu rather than being internal to the menu until publishing. A previous attempt had been made to fix that but it wasn't complete and resulted in the menu showing that it would "Publish" after setting it and closing/re-opening when in fact it would "Publish and send".
- moved all state for the distribution type and email settings to be stored in the `<PublishMenu>` component rather than split across the the component and model
- when saving a post from the publish menu, we now pass `emailOnly` as an option to the editor's save task the same as `sendEmailWhenPublished` (corresponding to the `email_recipient_filter` query param) so that we're back to one place controlling email behaviour for a post
- when `emailOnly` is passed as an option to the editor save task it will set the property on the model before saving and reset it back if the save fails. That way the email-only flag behaves as close to the "send when published" flag as possible without it also being sent as a query param.
refs https://github.com/TryGhost/Team/issues/947
- With email-only posts there's a new "send" status that deserved it's own publishing action in the post publish menu. With with addition the post ended up having few more publishing states: publish, send, and publish&send. In addition to all this there's a "schedule" option. An addition of the "send" only select option there became a need to persist the "email_only" flag when the option was changed in the publish menu. Such persistance was not done before from the publishing menu and led a whole chain of additional methods being passed down from publishmenu component all the way down to distribution-action-select component
- At this moment only a happy path work properly when selecting one of the publishing options and publishing. More states will need to be handled for scheduled, unblished, etc. states of the post
refs https://github.com/TryGhost/Team/issues/947
- There is no way to "unpublish" the email-only post that has been sent already. For current alpha version the menu is hidden and up for further development when needed
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
closes https://github.com/TryGhost/Team/issues/738
refs https://github.com/TryGhost/Admin/pull/1972
- when we switched from the segment select back to checkboxes and label select we lost the automatic member counting which meant other parts of the publishing workflow had no counts
- fixed subscribed status counts shown in publish menu
- added the async count back to the confirm modal, taking full free/paid/specific query into account
- added total subscribed member count back to the draft publish menu so the email options can be disabled when no subscribed members exist
- fixed missing disabled styling inside `<GhMembersRecipientSelect>`
no issue
Free and Paid are by far the two most common options for email recipients so it makes more sense to have them as very clear options which we felt was not the case with the single token/segment select.
- created a new `<GhMembersRecipientSelect>` component that has individual checkboxes for free/paid/segment and when segment is selected an additional token input for specific labels
- updated draft and scheduled publish menu components to use the `<GhMembersRecipientSelect>`
Co-authored-by: Sanne de Vries <sannedv@protonmail.com>
refs https://github.com/TryGhost/Team/issues/581
requires https://github.com/TryGhost/Ghost/pull/12932
- added segment option and select to default newsletter recipients setting
- updated segment selector to fetch labels/products and show as options
- updated segment selector and count component to call an action when count changes so we can use it in the email confirmation modal
- removed usage and mapping of older `'none'`, `'all'`, `'free'`, and `'paid'` email recipient filter values
refs https://github.com/TryGhost/Team/issues/496
reqs https://github.com/TryGhost/Ghost/pull/12925
The publish menu was meant to default to matching post visibility but that wasn't working consistently and didn't make sense for sites which don't email every post to their members.
A "Default newsletter recipients" option has been added to the "Email newsletter" settings screen and the publish menu updated to reflect the option. The free/paid toggles in the publish menu have also been swapped out for a multi-select style component that will cater to more complex member segmentation.
refs https://github.com/TryGhost/Team/issues/588
- The change allows to give information about not being able to send a newsletter along with publishing the post instead of waiting for a server response to fail
- Implements client-side limit check for email along with information coming from limit's error message
refs https://github.com/TryGhost/Team/issues/459
- using <GhBasicDropdown> in place of <BasicDropdown> hooks into our dropdown service which has more comprehensive body click tracking
No ref
- Updated all buttons in the editor header
- Updated buttons in publish menu
- Updated back-button in post-preview
- Updated icons for launch-site wizard
- Updated Stripe-info box in launch-site wizard
refs 6140a98351
- Adds free/paid member counts to newsletter option in publish menu
- Updates default state for newsletter sending option based on number of members for free/paid
- Updates styling for checkboxes based on enabled/disabled state
no issue
Keeps component JS backing files and template files in the same directory which avoids hunting across directories when working with components. Also lets you see all components when looking at one directory, whereas previously template-only or js-only components may not have been obvious without looking at both directories.
- ran [codemod](https://github.com/ember-codemods/ember-component-template-colocation-migrator/) for app-level components
- manually moved in-repo-addon component templates in `lib/koenig-editor`
- removed all explicit `layout` imports as JS/template associations are now made at build-time removing the need for them
- updated `.embercli` to default to new flat component structure
