refs https://github.com/TryGhost/Team/issues/1596
- Renamed `newsletter_id` to `newsletter` option, the `newsletter` option expects a slug instead of an id
- Renamed `email_recipient_filter` to `email_segment` option
- Default `email_segment` to `all`. Ignored if no newsletter is set
- `email_segment` is ignored if no newsletter is set
- When reverting a post to a draft, both `newsletter` and `email_segment` are reset to their default values (null, all)
- Removed legacy mapping from old email_recipient_filter values 'paid' and 'free' (already a migration in place)
- Dropped legacy throwing errors when email_recipient_filter is paid or free in transformEmailRecipientFilter
- Reorganized transformEmailRecipientFilter parameters for the now required newsletter parameter
- Fixed an issue where the newsletter filter wasn't working because it wasn't in permittedoptions
- Fixed an issue where you could send to an archived newsletter
- Added an extra protection when scheduling to an active, and later archiving the newsletter
- Dropped support for `send_email_when_published` in API
- When importing posts we currently don't have a system in place to set the newsletter_id to map the `send_email_when_published` behaviour. Since this was already the case, I won't include a fix in this PR.
- Stripped `email_recipient_filter`/`email_segment` from Content API (https://ghost.slack.com/archives/C02G9E68C/p1652363211841359?thread_ts=1650623650.233229&cid=C02G9E68C)
- Updated `admin-api-schema` to 3.2.0, which includes the new email_segment property
- Contains a temporary fix for https://github.com/TryGhost/Team/issues/1626, where the `.related('newsletter').fetch` call fails when the newsletter relation is already loaded, because of the overridden `formatOnWrite` method.
Since the `email_recipient_filter` is no longer used without a newsletter, the `none` value is no longer used. A migration transforms all those values to `all`. This should be safe, because we only send an email now when newsletter_id is not null (scheduled posts should already have a newsletter_id, even if at the time of scheduling they didn't add the newsletter_id option, because at that time, we defaulted to the default newsletter).
Admin changes to make this work: https://github.com/TryGhost/Admin/pull/2380
ref: https://github.com/TryGhost/Team/issues/1145
ref: 8f8b7e7364
- The /products/ endpoint was replaced with /tiers/ some time ago but we didn't finish the switch
- The work is complete now, so can remove the endpoint entirely and cleanup remaining usages
refs https://github.com/TryGhost/Toolbox/issues/314
- The API principle guiding this change is the Robustness Principle: "be conservative in what you send, be liberal in what you accept". The API will start accepting any additional properties that are not explicitly defined in the schema for the resource and will be trimming any rogue properties that are sent in the payload
refs https://ghost.slack.com/archives/C02G9E68C/p1651939076681719
Cause:
- When a scheduled post was published via the post scheduler, no `newsletter_id` option is passed when editing the post.
- When editing a post via the posts service, without the `newsletter_id` option, the `newsletter_id` option is automatically set to the default newsletter's id.
- Inside the post model, this new `newsletter_id` was not saved, because it was already set, and changing it is prevented.
- The `mega` service wasn't using the (unchanged) post's newsletter_id, but used the option instead, which contained the default newsletter's id.
Fix:
- Always using the newsletter_id from the post and requiring the newsletter associated with a post to exist.
- This behaviour can be/is tested by publishing a scheduled post without any option.
Also cleaned up some `Object.assign` usages.
refs https://github.com/TryGhost/Team/issues/1524
- We need to fetch the post newsletter to grab the slug as it's needed for the member NQL filter.
- We can then use the newsletter slug and append it in the existing member NQL filter.
- Removed `subscribed:true` when an email is sent to a newsletter and replaced it with the newsletter id
- Added `status:-free` when an email is sent to a newsletter with `visibility` set to `paid`
- Added tests what happens when you publish without newsletter_id
- Added tests what happens when you publish with newsletter_id
Co-authored-by: Simon Backx <simon@ghost.org>
refs https://github.com/TryGhost/Team/issues/1502
- Support the `newsletter_id` only when sending a newsletter
- Default to the default newsletter when `newsletter_id` isn't specified
- Ignore the `newsletter_id` parameter when passed in the post body
refs https://github.com/TryGhost/Team/issues/1004
The `tiers` column for a post/page only contained data if its visibility is set to `tiers`, otherwise its empty. This is because originally the purpose of `tiers` column on `post` was to capture specific tiers with access to post.
The best way to ensure a consistent behavior for `tiers` column data on post is to update it to always contain list of all `tiers` that have access to post, and not just when the visibility is `tiers`. This means the value is set to all tiers when visibility is one of public|members, and only paid tiers when visibility is `paid`. This change also allows on frontend to get all relevant `tiers` information for a post locally within post context instead of relying on additional information from outside.
This change -
- updates the output serializer for post/page to add all desired tiers manually in case of visibility is not `tiers`
- updates tests
refs https://github.com/TryGhost/Toolbox/issues/135
- Going though local utils allows to have the "withFrontend: false" flag applied only to the e2e-api test suites. This way we can gradually introduce the no-frontend change across all test suites
