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
refs https://github.com/TryGhost/Team/issues/1586
- added test helper for enabling/disabling members and helpers for disabling mailgun and newsletters
- added `loginAsRole` helper that alleviates duplication of user+role creation and also handles log-out before log-in so it's easier to mix different role tests within a block that has a default role setup in `beforeEach()`
- cleaned up editor tests that were skipped due to using the old publish flow
- added `Publish flow` acceptance test suite with an initial batch of tests
no issue
- the settings fixtures file was becoming hard to use because settings have been appended to it on an as-used basis which meant it was difficult to reason about the base-state in acceptance tests and was never really in sync with the default settings state for a Ghost site
- added a utility function to create a settings object with the `id` defined to avoid problems with manually updating the ids in the list
- updated to include all default settings with their default values if not already set to a specific testing value in the old fixtures
no issue
- some tests were unnecessarily slowed down by waiting repeatedly for animations to complete
- added override for `<LiquidContainer>` component that `<LiquidIf>` uses internally with the only change being to set the default growth animation duration to 5ms when running tests
no issue
- `<KoenigBasicHtmlTextarea>` has no UI or keyboard shortcut support for blockquotes but the markdown text expansion for quotes was left in despite the code required for it not existing, this meant any time `> text` was typed the editor would throw errors due to missing actions
refs TryGhost/Team#1652
- Support picking new image types in the favicon image uploader.
- Added support for non-square and not resizable files (e.g., svg files) as favicon (cover background image).
closes https://github.com/TryGhost/Ghost/issues/14018
- product card descriptions and toggle card content both use `<KoeingBasicHtmlTextarea>` which is a stripped down Koenig editor with basic formatting support where heading sections are not expected
- when pasting into or updating the content in `<KoeingBasicHtmlTextarea>`, convert any headings, blockquotes, or other markerable section types to standard paragraphs so the content formatting matches what is possible through the editing interface
refs https://github.com/TryGhost/Ghost/issues/14101
- dropped usage of `<GhTrimFocusInput>` and `<GhTextInput>` in favor of native input elements for more explicit behaviour
- switched `SignupController` to native class syntax
- migrated to `@action` decorators and swapped all template action triggers to `{{on}}` and `{{fn}}`
refs https://github.com/TryGhost/Admin/pull/2286
- the UI to upload a profile image during setup/signup was removed as part of the auth screens redesign but the related code was left behind
no issue
- ensure tasks return `true` or `false` so the button states reflect reality
- added `@showSuccess={{false}}` to both forms because they automatically switch to a new screen on success so there's no point showing a flash of the success state
- removed unnecessary and not-recommended tabindex properties on form elements
refs https://github.com/TryGhost/Team/issues/1613
We use `notifications.showAPIError()` in many of our try/catch routines but those can also pick up standard JS errors which can result in ugly and useless messages showing in alerts.
- added a list of known built-in JS error type names to check against and a generic error message to be used in place of ones we know shouldn't be displayed
- in `showAPIError(obj)` check `obj.name` against the known list and swap the message for a generic one
- only the message is swapped, we still log the full/original error to Sentry
- in `handleNotification(msg)` which is the final method used when displaying any alert/notification, extract all words in the supplied message and check that against the known list and swap the message on a match. This handles situations where the API might give us a raw JS error message in the message string
refs a021553203
- keeps text and logic together, avoids duplication of button code just for changing the running/success text
- added a `buttonTextMap` to keep the high-level text states in one place
- added `publishType` getter for easier switching between states in other getters and to have one place for the logic
- updated `confirmButtonText` getter and added `confirmRunningText` and `confirmSuccessText` getters that read from the button text map so the pattern used for getting text to pass as arguments in the template is consistent
no issue
When adding cards to the editor, especially image cards, we were seeing the cards removed instantaneously or whilst the file dialog was open making it appear that nothing had happened after selecting the card in the menu or selecting a file.
- as part of the publish flow workflow we extracted the pre-save routine into a separate task so that it could be triggered from external components
- one of the pre-save routine actions was to trigger an editor cleanup that removes empty cards and trailing paragraphs _but_ it should only do that when not performing a background save that occurs on any change to the post contents for drafts
- the problem arose from the background saves because the `options` argument was never passed through to the `beforeSaveTask` call meaning every save looked like a full save and performed editor cleanup resulting in unexpected removal of empty cards that had just been created
no issue
When adding cards to the editor, especially image cards, we were seeing the cards removed instantaneously or whilst the file dialog was open making it appear that nothing had happened after selecting the card in the menu or selecting a file.
- as part of the publish flow workflow we extracted the pre-save routine into a separate task so that it could be triggered from external components
- one of the pre-save routine actions was to trigger an editor cleanup that removes empty cards and trailing paragraphs _but_ it should only do that when not performing a background save that occurs on any change to the post contents for drafts
- the problem arose from the background saves because the `options` argument was never passed through to the `beforeSaveTask` call meaning every save looked like a full save and performed editor cleanup resulting in unexpected removal of empty cards that had just been created
no issue
- we had a mix of legacy jQuery triggers and native triggers for file input clicks and jQuery hasn't been required to do this in our target browsers for quite a long time now so it made sense to update all click triggers to avoid old patterns being replicated
- cleaned up some conditionals with optional-chaining
- removed use of `run.bind(this)` for methods that use `@action` because the binding is already handled for us
closes https://github.com/TryGhost/Team/issues/1647
- sending the embedded `email` record back to the API when saving could trigger "Request entity too large" errors for very large posts that were sent as email because it doubles up on the request size
- `post.email` is a read-only property and is ignored by the API so there's no point serializing it and making request bodies larger than they need to be
refs e021843e3f
- fixed closing of alerts due to missing `.args` after migrating to glimmer syntax
- updated related tests for glimmer component syntax
no issue
- migrated `notifications` service from EmberObject to true native class
- switched to tracked properties and use of `TrackedArray`
- swapped computed properties to getters
- dropped unnecessary usage of `get` and `set`
- migrated alert/notification related components to Glimmer components
no issue
- the relationship is no longer used (it was a temporary solution whilst we built full member events) and was never fully set up resulting in warning output in test runs
- dropped remaining vestiges of the relationship
no issue
`ember-cli-mirage` replaced the use of a default function export with a `createServer` function that applies config and deprecated the older mirage config export style. It will also soon drop support of the separate `testConfig` export we used for defining our test routes.
- switched to the newer `return createServer(config);` server configuration approach
- extracted dev and test routes into separate files for a cleaner base config
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 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
refs https://github.com/TryGhost/Team/issues/1575
- Update usage of Tier to read monthly & yearly price & currency from top level
- Updated usage of Tier to read benefit name from benefits[n], not from benefits[n].name
Co-authored-by: Fabien "egg" O'Carroll <fabien@allou.is>
no issue
- updated `<PublishManagement>` and sub-components to handle contributors by replacing publish button with save button in main view and in preview
- removed feature flag gating and usage of `<GhPublishmenu>` in editor template
- updated tests that indirectly used the old publish menu so they work with the new design/behaviour
- skipped editor tests that used the old publish menu
refs https://github.com/TryGhost/Team/issues/1621
reqs https://github.com/TryGhost/Ghost/pull/14820
We want to allow previewing emails based on the newsletter selected in the publish flow.
- passed the selected newsletter from `<PublishManagement>` through to the preview modal then through to the email preview component
- removed tracked `newsletter` property and fetching of the default newsletter in the email preview component that was in place to allow `senderName` and `senderEmail` to be used in the component
- added `newsletter` getter that uses the `post.newsletter` or the passed in selected newsletter
- updated the email preview fetching to pass `?newsletter=slug` so the email is rendered with the correct newlsetter
refs: TryGhost/Team#1625
- we want to remove backwards compatibility code for slack being a single setting
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
no issue
- removed "cmd+p" shortcut from the main editor element
- added "cmd+p" shortcut to `<PublishManagement>`
- toggles the preview modal on/off
- closes the publish modal if it's open when switching to the preview modal so we don't end up with both modals open simultaneously
- fixed "Preview" button not showing up for contributors
- this still uses the old preview modal for now
- contributor preview/save should be handled inside the new publish flow later on
refs https://github.com/TryGhost/Team/issues/1596
This commit updates admin to align with the changes in the backend in https://github.com/TryGhost/Ghost/pull/14798
- `post.email_recipient_filter` option and property is renamed to `email_segment`
- `newsletter_id` option is renamed to `newsletter` (and now uses slug instead of id)
- Sending a post via email, means you need to set the `newsletter` option. The `email_segment` option is optional now and defaults to `all`. Not setting `newsletter` means not sending an email, setting `email_segment` is ignored if `newsletter` is missing.
- We can no longer use `email_recipient_filter` (now renamed to `email_segment`) to know whether a post is published/scheduled to be sent as an email. We need to rely on the newsletter relation now. The `email_segment` `none` value has been dropped and will be `all` even if no email will be sent (newsletter will be null).
- `sendEmailWhenPublished` option is no longer supported in the backend.
refs https://github.com/TryGhost/Team/issues/1621
- added `currentTab` and `changeTab()` data arguments to preview modal allowing for the current tab to be remembered across opens in the `<PublishManagement>` component that controls open/close of the preview modal
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
