no issue
- the API response is now empty so returning the parsed response is null/undefined resulting in `<GhTaskButton>` showing a failure state
- switched to returning an enforced `true` value, if there was an error that's handled by the try/catch
refs https://github.com/TryGhost/Team/issues/1650
- Some places only checked for Stripe being connected via the 'connect' method and ignored the 'direct' method
- Updated (where possible) admin to use the new calculated `paid_members_enabled` setting
no issue
- if a markdown card is created and destroyed before the simplemde+codemirror instance is fully initialised we could throw errors due to simplemde calling methods on objects that don't yet exist during teardown
- we also had issues with the `_applyToolbarStyles()` method being called async by event handlers after the component was destroyed
no issue
- selecting a date in a future month always selected the same day number in the current month, if that was in the past it would also reset to "in 5 minutes"
- we were grabbing the day/month/year from the moment object provided by the calendar picker but we weren't using the correct property names, moment.js uses `months` and `years` instead of `month` and `year`
no issue
- fixed incorrect conversion of time when converting between site tz and utc when setting scheduled hour/minute in publish flow
- we initially created a UTC `newDate` moment from `publishOptions.scheduledAtUTC` but then used `newDate.tz(siteTimezone).format()` to get the time which was the source of the bug, it was assumed that was a non-destructive action returning a new date but it actually changed the underlying date resulting in the later calculations causing timezone adjustments to be applied twice
- simplified by not converting to UTC inside the publish-at component as that's already handled inside PublishOptions
- fixed time not resetting to minimum schedule time when set to earlier date than allowed
no issue
Problem:
- the server stores time with second-level precision but we send milliseconds
- when scheduling a post we were storing the selected publish-at time in the PublishOptions instance with non-zero milliseconds as the initial date was based on now+5mins
- when we were saving after the initial schedule that millisecond-containing time was still being used resulting in a perceived time difference in our client-side and server-side validations indicating that the published_at value should be updated, but when that time was <2 mins in the future the published_at change validation was triggered resulting in errors
Solution:
- ensure we only set times on PublishOptions with 0 milliseconds
- update client-side validations so we only trigger published_at validation when it's dirty
Also fixed:
- client-side validation errors were not shown on the confirm step due to a missing `.args`
refs 2fb62708a8
- use modal's own `.epm-out` class that's added when closing to trigger the reverse of the fade-in animation
- added `.publish-modal` class to the three publish modals so we can alter the default modal animations/timing if required
no issue
- updated the publish/preview toggle action to pass a `skipAnimation` data attribute to the modals when opening if they are being swapped rather than initially opened
no issue
- "subscriber" makes more sense than "member" in the default-only newsletter state because members still need to be subscribed to the default newsletter
- removed all subscriber/member conditionals and cleaned up template logic where possible
no issue
- adds `{{get-setting "key"}}` helper to make settings available in templates without needing a backing class
- updated `<GhPostBookmark>` component
- if post feature image isn't present, fall back to site cover image
- add site icon (if present) and title to the details line
- removed author image
Co-authored-by: Sanne de Vries <sannedv@protonmail.com>
refs https://github.com/TryGhost/Team/issues/1634
- member count on newsletter may not be immediately updated on saving newsletter
- api returns `opted_in_member_count` in response to adding newsletter which admin cannot use atm
- re-fetches newsletters on save so all newsletters get updated member and post counts
no issue
- authors/editors don't yet have a way to fetch member counts for specific filters so the final member count is hidden in the publish options text, however we were still showing the total subscribed members for each newsletter in the dropdown which could lead to incorrect assumptions for how many members would receive the newsletter
refs https://github.com/TryGhost/Team/issues/1477
- Added default test fixture
- Added tests for validation of newsletter when editing
- Added tests for opening and closing tabs
refs 89f089e439
- if "Free" or "Paid" had already been output we were still capitalising "Subscribers" ending up with "Free Subscribers" instead of "Free subscribers"
- adjusted the capitalisation conditionals so we don't capitalize "subscriber(s)" if we've already output the recipient type
no issue
- `{{format-number}}` was showing "0" when passed in an empty/nullish string when it should have been showing nothing
- used `{{if-empty}}` to fix capitalisation when the member count is missing
- previously attempted a CSS-only fix with `:first-letter` and `text-transform: uppercase` but that broke the layout in Safari