no issue
- the `post.willEmail` computed property was not taking into account an existing email so when re-scheduling the publish of a post that had previously been emailed the complete step showed "will be published and sent" rather than the correct "will be published"
refs https://github.com/TryGhost/Team/issues/1587
- if post creation succeeds but the email fails to send we want to show a separate state of the publish flow rather than adding an error to the confirm step
- confirm _has_ completed so showing the error there doesn't make sense and causes confusing copy
- added check for email failure to the `<PublishFlow>` save task (which is called by the confirm step) to intercept any email failure errors and switch state
no issue
- CI keeps failing on this test because Firefox is being slow and hitting the 15sec timeout
- skipped for now as it's testing an old flow that no longer exists and the test will be replaced with an updated version soon
refs: https://github.com/TryGhost/Toolbox/issues/327
requires: TryGhost/Ghost#14791
- lang / locale has had a lot of churn, but we decided this setting should always be locale
- Removed test relating to unused editor_is_launch_complete setting
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
no issue
- it was possible to enter invalid times when scheduling in the publish flow, in which case the underlying schedule date was not updated but the input still showed the invalid time
- added passthrough of the blur event in `<GhDateTimePicker>` to the `setTime` action so we have access to the input field, then updated the `setTime` action to set the time input value back to the currently set schedule time when an invalid time is entered so the UI matches the actually set value
no issue
- `publishOptions.willEmail` doesn't work for the conditional because it will be false when no email will be sent, which is the case when a recipient filter is the equivalent of "none"
- switched to being conditional on the publish type and added a separate "Not sent to any members" conditional for `recipientFilter` being blank so we're not showing an incorrect count of members
no issue
- there are no restrictions on Editor/Author emailing on the API side
- removed `user.canEmail` computed property as it's only contributors that don't have publish/email permissions and they aren't shown the publishing flow anyway
no issue
- used CSS rather than `{{capitalize}}` to avoid multiple conditionals for something that's edge-case and will eventually disappear once member counts are available to all roles that can send email
closes https://github.com/TryGhost/Team/issues/1622
- we were setting selected hour/minute on a supposedly site-timezone date before converting to UTC but we were using a local timezone date instead meaning the conversion to UTC didn't match resulting in the time being altered incorrectly after the time input loses focus
no issue
- show the newsletter a post was/will be sent to if there's more than just the default newsletter or the newsletter that was emailed is now archived
refs https://github.com/TryGhost/Team/issues/1621
- copied existing preview modal over to `editor-labs/modals` directory
- old modal will be deleted in cleanup
- moved "Preview" button from editor template to the `<PublishManagement>` component
- allows for preview modal to be controlled alongside the publish flow modal
- added `togglePreviewPublish()` action to `<PublishManagement>`
- opens whichever of preview/publish is not currently open, this opens the new modal on top of the old modal
- waits for the modal animation duration to pass then closes the modal that's now underneath, this prevents the flashing that occurs when modals are both opening and closing at the same time because that results in a 50% opacity of both modals during the middle of the animation
- updated preview modal and publish-flow modals to have "Publish" and "Preview" buttons respectively that call the `togglePreviewPublish` action
- updated preview modal to be fullscreen to better match the publish modal
refs https://github.com/TryGhost/Team/issues/1621
- the old publish menu will be fully deleted soon
- removing it from the preview modal is the minimal "fix" for interoperability with the new publish flow
- pre-cursor to tighter preview/publish modal integration
