no issue
- the modal instance on `this.top` inside the background click handler is not always a direct instance so we need to check both `.options` and `._options` when looking for the desired click ignore behaviour
refs https://github.com/TryGhost/Team/issues/1673
When a user switches plan, the paid subscribers delta chart on the dashboard displays the change as a cancellation plus a new subscription. This display is misleading and confusing - instead, plan changes should be excluded from the paid subscribers delta chart.
refs https://github.com/TryGhost/Ghost/issues/15008
- When the user is removed the new flow adds a special tag and reassignes all the user-owned posts to the owner user. Updated copy to inform about this behavior clearly
refs https://github.com/TryGhost/Ghost/issues/15008
- Backup process had a slim benefit to keep around. Without it the removal process is much smoother.
- The backup still happens on the server side if it's absolutely needed at some point in the future
no issue
- `event.timestamp` was used instead of `parsedEvent.timestamp` meaning it was undefined and `{{moment-format}}` created a new date object instead of using the real event date
no issue
- in sites with a timezone that is negatively offset from UTC at certain times of day when the equivalent UTC date would be the next day, selecting a date when scheduling a post would select a day before the selected date
- fixed the date adjustment when applying the selected date to properly take timezones into account
no issue
- with large site timezone UTC offsets it could happen that "today" in the site timezone is not selectable in the date picker when scheduling posts
- the problem occurred because we were passing a minimum date to the date picker in UTC which was then converted to a local date using just the "YYYY-MM-DD" data but that would not always be correct because the UTC date could be "tomorrow" compared to the site timezone. Passing in the minimum date in the site timezone rather than UTC ensures the minimum date always matches "today" in the site timezone
no issue
- with large site timezone UTC offsets it could happen that "today" in the site timezone is not selectable in the date picker when scheduling posts
- the problem occurred because we were passing a minimum date to the date picker in UTC which was then converted to a local date using just the "YYYY-MM-DD" data but that would not always be correct because the UTC date could be "tomorrow" compared to the site timezone. Passing in the minimum date in the site timezone rather than UTC ensures the minimum date always matches "today" in the site timezone
no issue
- in sites with a timezone that is negatively offset from UTC at certain times of day when the equivalent UTC date would be the next day, selecting a date when scheduling a post would select a day before the selected date
- fixed the date adjustment when applying the selected date to properly take timezones into account
no issue
- renamed "Update" to "Unpublish" or "Unschedule" to match the available actions
- renamed "Save" to "Update" and made it always visible but disabled when there are no unsaved changes
- switched <Editor::PublishManagement> to a provider component and extracted `<Editor::PublishButtons>`
- allows for the management flow to wrap other UI elements and have the yielded actions passed down so the publish/update flow can be opened from more than just the publish/unschedule/unpublish buttons
- added link to "Sent" in editor status that opens the update flow for email-only posts
Co-authored-by: Peter Zimon <peter.zimon@gmail.com>
refs https://github.com/TryGhost/Team/issues/1586
- updated `?newsletter_id=id` handling in posts API mock to match the real `?newsletter=slug` behaviour
- added additional publish flow acceptance tests for single/multiple newsletter behaviour, scheduling, and sending
no issue
The default recipients setting "Usually nobody" was being respected with the email recipient list defaulting to no members selected. However the UI for that state was confusing because the default publish options ended up being "Publish and email" and "Not sent as a newsletter" but it was expected to be "Publish" with the newsletter option being disabled.
- updated the `PublishOptions` setup to reflect the desired outcome for "Usually nobody"
- default publish type is set to "Publish"
- default email recipients are set to match post visibility - this means there are fewer clicks required when switching from "Publish" to "Publish and send"
- updated mirage data setup so any members created are automatically assigned to any newsletter instance with `subscribeOnSignup` set
- ensures we get proper member counts in the publish flow
