fixes https://github.com/TryGhost/Team/issues/2008
- New column that stores email click tracking at the time it was created
- Improved frontend side checks for when to show analytics
fixes https://github.com/TryGhost/Team/issues/1992
When you edit a post via the editor, the back button on the top of the editor should go back to the analytics page and the status at the top should be removed.
no issue
Since `ember-moment@10.0` it's not been necessary to use the `ember-cli-moment-shim` package, with `moment` instead being usable directly via `ember-auto-import`. Getting rid of the shim package is necessary for compatibility with `embroider`, Ember's new build tooling.
- dropped `ember-cli-moment-shim` dependency
- added `moment-timezone` dependency and updated all imports to reflect the different package
- worked around `ember-power-calendar` having `ember-cli-moment-shim` as a sub-dependency
- added empty in-repo-addon `ember-power-calendar-moment` to avoid `ember-power-calendar` complaining about a missing package
- added `ember-power-calendar-utils` in-repo-addon that is a copy of `ember-power-calendar-moment` but without the build-time renaming of the tree for better compatibility with embroider
closes https://github.com/TryGhost/Team/issues/1924
- updated the Post model so the relevant `mobiledoc`/`lexical` field always has a blank document by default depending on which editor is selected via the feature flag
- ensures we don't send `{mobiledoc: null, lexical: null}` inadvertently creating a mobiledoc post (API sets the default blank document in that scenario) when the lexical editor flag is enabled
fixes https://github.com/TryGhost/Team/issues/1900
refs https://github.com/TryGhost/Team/issues/1901
- Defaults to the same value as the current email_track_opens setting for existing installations, otherwise defaults to true
- Had to use a custom migration because the `addSetting` helper doesn't support using an existing setting as current value
- Added a minimal UI to change the setting, but this still needs some design magic 🪄✨
- Link replacement is disabled if `email_track_clicks` is disabled. In the future we might consider to still do parial additions, such as source attribution and maybe redirects (to discuss).
no issue
- fixed API returning "Invalid mobiledoc structure" errors when `mobiledoc:null` is sent in the payload alongside `lexical: '{...}'`
- updated Admin's `posts` and `pages` adapters to always add `?formats=mobiledoc,lexical` because the API doesn't return `lexical` by default
- added `lexical` attribute to Admin's Post model
- updated `lexical-editor` controller and related components to work with `lexical` always being a JSON string rather than a parsed object
- updated `<KoenigLexicalEditor>` to pass through the lexical state string as initial state and wired up the `onChange` prop
no issue
- mobiledoc and lexical editors will co-exist for some time so we want to make using both as straight forward as possible
- posts can only have one of `lexical` or `mobiledoc` properties set so in the `edit` route for each editor we detect the opposite property being present and redirect so the right editor is loaded for each post
The Posts API does not strip unknown properties when dealing with relations,
which meant that tags were being sent up with a `parent` property which would
always cause the model to be considered "changed". This resulted in the update
methods being called, and leading to unexpected behaviour.
Whilst this change does fix things for the History feature, the correct fix is
to update the admin-api-schema, or the input serializers such that they only
allow through known and allowed properties.
refs TryGhost/Team#1826
- allows staff users to manage their email alert settings behind the flag
- only owner and admin users are able to toggle their email alerts
refs https://github.com/TryGhost/Team/issues/584
- No longer uses a API URL + redirect inside verification emails. This is replaced by a new route (`/settings/members/?verifyEmail=token`) that does the API request and shows a modal.
- Removed update button when changing support email address in the Portal settings
- Added `_meta` attribute to settings (uses same pattern as newsletters model)
- When updating the `membersSupportAddress` setting (via the normal edit endpoint), the `sent_email_verification` meta property will get set by the API. When this new property is present, we'll show a warning that the support address requires verification.
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
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
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>
refs: TryGhost/Team#1625
- we want to remove backwards compatibility code for slack being a single setting
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
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.
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/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
- 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
refs: https://github.com/TryGhost/Team/issues/1145
- this should allow us to remove the /products endpoint in v5
It avoids:
- `kg-product-card`, that really is meant to say product
- `product-cadence` on offers
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
refs https://github.com/TryGhost/Team/issues/1576
- Recipient counts in scheduled post status at top of editor fixed for selected newsletter
- Added `fullRecipientFilter` getter on post model which includes the newsletter's recipientFilter
- Updated scheduled notification (used in old publishing flow or via preview)
- Admin used a helper to generate Gravatar URLs for members
- This change switches to using the `avatar_image` returned by the Member API
- The helper predates the existence of `member.avatar_image`, and is no longer required
refs https://github.com/TryGhost/Team/issues/1576
- Passes the selected newsletter to the recipient selector
- Added a `recipientFilter` getter to the newsletter model to make changes easier in the future
- Updates the `fullRecipientFilter` in the new publishing flow to use the newsletter's recipientFilter
- Already takes future paid only newsletters into account
- The counts in the status message after publishing is not updated yet (requires https://github.com/TryGhost/Team/issues/1569)
- The counts in the scheduled notification is not updated yet (requires https://github.com/TryGhost/Team/issues/1569)
no issue
If you scheduled a post to a specific newsletter it was no longer visible in the scheduled state of the publish menu making it difficult to know the behaviour when coming back to a scheduled post.
- duplicated the newsletter dropdown from the draft to the scheduled state components and disabled it the same as the other recipient options
- added temporary workaround for missing newsletter embed for the posts endpoint in the API
- adds `newsletterId` attribute to the post model
- uses `post.newsletterId` to find the matching newsletter model from the available newsletters list
refs https://github.com/TryGhost/Team/issues/1542
- adds a `PublishOptions` class
- an instance of this class provides everything the UI needs to display and set the publish options relevant to the current post object and overall system state
- the `publish-flow` modal is passed a `PublishOptions` instance when it opens
- as part of the constructor it triggers a background load of any additional data it requires to control available options such as member counts, email limits, and newsletters
- adds a `{{publish-options}}` resource
- sets up and returns `PublishOptions` instance
- passes through service dependencies which are not available directly in the `PublishOptions` class as it's a custom native class outside of Ember's DI management
- used to ensure we can get a clean `PublishOptions` instance any time the passed in `post` object is replaced meaning we don't have to rely on observers and manual teardown/setup
- updated `<PublishManagement>` component
- sets up `publishOptions` property using `@use` and the `{{publish-options}}` resource so reactivity for changing post objects is handled automatically
- uses the `publishOptions.isLoading` property to disable the publish flow trigger button until all of the data required to manage the flow is available
- updated `publish-flow` modal to use some of the initially available `publishOptions` data
refs https://github.com/TryGhost/Team/issues/1532
- added `showHeaderName` attribute to newsletter model
- added attribute toggle to the newsletter design settings form
- updated newsletter preview behaviour
- if both title and name are on, show name as a subtitle
- if title is off but name is on, show name as main title
- adjusted higher-level "show header" and "show header title" conditionals to account for the new setting
refs https://github.com/TryGhost/Team/issues/1492
Allows site owners to manage member's newsletter preference directly in Admin.
- also adds `visibility` property for newsletter model
- updates members test model to include `visibility`
refs e398557a75
- `resetEmailAddresses()` was called when saving the labs version of members-email settings screen but the function no longer exists, this was throwing an error which broke all following tests in CI
refs https://github.com/TryGhost/Team/issues/584
refs https://github.com/TryGhost/Team/issues/1498
- updated newsletter save routine in `edit-newsletter` modal to open an email confirmation modal if the API indicates one was sent
- modal indicates that the previously set or default email will continue to be used until verified
- response from API when saving looks like `{newsletters: [{...}], meta: {sent_email_verification: ['sender_name]}}`
- added custom newsletter serializer and updated model so that the `meta` property returned in the response when saving posts is exposed
- Ember Data only exposes meta on array-response find/query methods
- https://github.com/emberjs/data/issues/2905
- added `/settings/members-email-labs/?verifyEmail=xyz` query param handling
- opens email verification modal if param is set and instantly clears the query param to avoid problems with sticky params
- when the modal opens it makes a `PUT /newsletters/verify-email/` request with the token in the body params, on the API side this works the same as a newsletter update request returning the fully updated newsletter record which is then pushed into the store
- removed unused from/reply address code from `<Settings::MembersEmailLabs>` component and controller
- setting the values now handled per-newsletter in the edit-newsletter modal
- verifying email change is handled in the members-email-labs controller
- fixed mirage not outputting pluralized root for "singular" endpoints such as POST/PUT requests to better match our API behaviour
refs https://github.com/TryGhost/Team/issues/1500
- `senderEmail` is now nullable with a fallback to `noreply@{site domain}`
- `senderName` is not nullable and has no fallback
- updated preview and input placeholder to match real-world behaviour
- inserted site title as the default value when creating a new newsletter to avoid friction with the sender name needing to be filled in when saving
- switched `senderReplyTo` input field to a select with "newsletter" and "support" options
- added basic `<Inputs::Select>` component as `<OneWaySelect>` had re-rendering issues causing loss of selected value when the label of the newsletter email changed to reflect a custom newsletter email value
closes https://github.com/TryGhost/Team/issues/1479
- updated post adapter to append `?newsletter_id=xyz` when passed a `newsletterId` adapterOption
- updated editor save task to pass `options.newsletterId` through as `adapterOptions.newsletterId`
- set up `post.newsletter` relationship ready for handling embedded newsletter association from the API
- explicitly deleted when serializing back to the API as it doesn't yet ignore the attribute
- updated `<GhPublishmenu>` for newsletter support
- fetches newsletters on first render so they are available in the dropdown
- sets "default" (first in the ordered list) newsletter as the initially selected newsletter
- adds newsletter dropdown to draft publish menu
- passes `newsletterId` option to editor save task when it's set
This is a minimal implementation for testing. Not included:
- correct free/paid member counts based on selected newsletter
- correct member count in confirmation modal
- indication of selected newsletter for scheduled post
refs https://github.com/TryGhost/Team/issues/1441
- switched "leave settings" confirmation modal on members email settings screen over to modern modal pattern
- removed unused `showEmailDesignSettings` property and `closeEmailDesignSettings()` action on `<Settings::MembersEmailLabs>` component
- the used property and action live on the controller, looks like it was a copy/paste hangover when functionality was moved to a component
- added newsletter model
- includes design-related attributes which are not yet supported by the API but are due to be added
- includes `default` attribute but there is no setting for it, due to be removed from the API but it's needed for save not to error for now
- set up basic mirage model and endpoints
- added validation for main settings to match API validation
- added `EditNewsletter` modal
- separate tabs for general newsletter settings and design-related settings
- used for both creating and editing newsletters
- added `/settings/members-email/newsletters/new` and `/settings/members-email/newsletters/:id` routes
- both display the `EditNewsletter` modal on top of the members-email settings screen with the appropriate newsletter model
- updated `<Settings::MembersEmailLabs::NewsletterManagement>` component to work with real newsletter model instances and the new add/edit routes
- removed now-unused `newsletter` service that was providing mocked data for earlier design iteration
refs https://github.com/TryGhost/Team/issues/1423
- problem:
- all members requests were automatically adding `?include=email_recipients` as the email recipients relationship was set up to be always embedded
- embedded email_recipient records also embed the whole email record
- on the members index screen this meant for each of the 50 members loaded on a page we were also loading every email they have ever received resulting in a huge API response
- this was not a problem previously because the API was ignoring the `include` parameter on the browse endpoint and Admin wasn't formatting the include properly in snake_case
- solution:
- the only place we need associated email recipients is on the member details screen where they are used to show the email activity feed
- removing the `{embedded: 'always'}` option for the `member.emailRecipients` association stops `?include=email_recipients` being added automatically to every members request
- the member details screen explicitly adds `?include=email_recipients` so no further changes are needed
- activity feed will be changing to use proper event objects in the future and further optimisation can be made
