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 d11cf9e1c7
- "free subscribers" worked but "paid" and "all" states still had "members" in the fixed string along with the new "members/subscribers" plural variable resulting in text like "all memberssusbcribers of My Newsletter"
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
no issue
- the title comparison in the editor's `hasDirtyAttributes` CP was comparing properties on the wrong object so never returned `true` when the title was changed
