no issue
- New fields that are accepted through members CSV import endpoint are:
- `subscribed_to_emails` - corresponds to `subscribed` flag in API
- `stripe_customer_id` - links existing Stripe customer to created member
- `complimentary_plan` - flag controlling "Complimentary" plan subscription creation for imported member
- Noteworthy exception in field naming - `subscribed_to_emails` that corresponds to `subscribed` API flag present on members resources. It's a special case of CSV format, where users can be less technical it's more explicit to what the flag does (also the same naming is applied in the Admin UI)
- Failing to either link Stripe customer or assign "Complimentary" subscription to imported member behaves in a transaction-like manner - imported record is not created in the database. This is needed to be able to retry imports when it fails for reasons like connectivity failure with Stripe or Stripe miss-configuration.
- To avoid conflicts with linking same Stripe customer to multiple members there is a special handling for duplicate `stripe_customer_id` fields. Records with duplicates are removed from imported set.
no issue
- a couple of regressions tests would repeatedly fail on CI. They would
always follow tests that closed the Ghost server beforehand.
- this commit doesn't close the server after those tests have completed,
which is similar functionality to all other tests
- the actual cause is unknown at this point, but I suspect it's some
sort of race condition
no issue
- We need a way to simulate "premium" membership without any payment from members' side. For this new "Complimentary" plan is introduced
- Allows `comped` flag as an input only on `PUT /members/:id` endpoint which sets free subscriptions based on "complimentary" plan on the member
- Added `comped` flag to members endpoint responses
- Bumped members-api to 0.12.0. This version supports new set/cancel complimentary subscription methods
refs https://github.com/TryGhost/Ghost/issues/10471
- Allow page resource endpoints to accept HTML source. This behavior is the same as the post's resource introduced with e9ecf70ff7372f395b8917340805148bc764e2ef
- The functionality was most likely missed when post split into posts & pages was happening.
- Added symmetric changes to API v2.
refs https://forum.ghost.org/t/plaintext-value-is-empty-using-the-api/10537
- The `plaintext`/`html` fields were empty because `visibility` attribute was not present in response body on output serialization stage. `visibility` field is always needed for content gating to work as expected
- Added `visibility` field in the input serialization layer as it wouldn't be possible to use content gating if added on model layer through `defaultColumnsToFetch`
- Added test cases covering a bug
no issue
- There was a lack of any kind of tests checking if content gating
behaves as it should. These changes create a base to expand upon when
more changes are introduced into content gating mechanism
- One thing that would be great to add in the future is imitation of
member authentication to test the content is visible for authenticated
paying/non-paying members
- Added 'members only' tests
- Added 'paid' post test case
- Added plaintext gating test case
refs https://github.com/TryGhost/Ghost/issues/11461
- The email feature was introduced in API v3 and is not back compatible with API v2. These fields should not appear in any v2 responses.
- Added regression tests for API v2 so that cases like this are spotted
easier in the future.
refs https://github.com/TryGhost/Ghost/pull/11152
- Added subscribers table drop migration
- Removed subscribers from schema
- Removed subscribers controllers/routes/regression tests
- Removed subscriber related API code
- Removed subscribers from internal apps
- Removed subscriber importer
- Removed subscriber model
- Removed subscriber related permissions
- Removed webhook code related to subscribers
- When upgrading to v3 it is on the site admin to migrate all zapps or any other webhook clients to use members
- Removed subscriber-specific translation
- Removed subscriber lab flag
no issue
- Added test cases to check edit permission on settings endpoints
- Added test to demonstrate owner-only being able to toggle members flag
- Permission check when editing settings `lab.members`
- Passed additional function to permissions to allow custom selection of unsafe attributes due to settings object structure.
- Fully implementing this check on controller level would be wrong architecturally and not that straight forward because we lack role data in "frame"
- Cleaned up test after moving default_content_visibility to it's own property
no issue
- Improved error handling for member creation. We should be returning 422s instead of 500 when possible
- Wrapped `members.add` method with Bluebird promise. Wrapping is needed to be able to use `.reflect()` in CSV export method
- Added proper members CSV fixture
no issue
- Added Regression full test coverage for members Admin API
- Added `POST /members` endpoint
- Added members schema definition + validation
- Added ability to pass through send_email/emal_type options to members API
no issue
- Removed uses of `visibility` column in frontend url service configs
- The value of `visibility` is always set to 'public' in posts at the moment and doesn't serve any specific purpose when used with these filters.
- Allowed new visibility attributes in post model
- `posts.visibility` column is being repurposed for the needs of member content gating
- Added test for visibility editing in Admin API
- Corrected test schema checks for Admin API post/page responses
no issue
- Updated test utilities to clearly identify both fields are not used in API responses
- Updated comment to remember clearning authors/author_id before releasing Ghost 4.0
refs #5151
refs #10737
- Removed all uses/references to post's "staticPages" filter
- It was only a feature specific to API v0.1 which doesn't have to take space in the codebase anymore
refs https://github.com/TryGhost/Ghost/issues/10922
- adds migrations to...
1. add `post.type` column
2. populate `post.type` column based on `post.page` value
3. drop `post.page` column
- updates all code paths to work with `post.type` in place of `post.page`
- adds `nql-map-key-values` transformer for mapping `page`->`type` in `filter` params when using the v2 API
- modifies importer to handle `post.page`->`post.type` transformation when importing older export files
NOTE: The post metadata table split is purely an internal optimization for v3 and doesn't require or expect any external actions including related API usage in v3
We keep running into issues adding new fields to the post table because there are too many fields making the post table "too wide". We have also hit MySQL limitations in how many bytes can be in a row (64kb) with post table.
In v3, we decided to split the 8 post fields (meta, twitter and og) used for meta data into a posts_meta table as these 8 fields are all "problem" `varchar` fields and make sense logically grouped together. The API layer is unaffected by the split as input/output serializers ensure the data flow works the same way as it was in v2. Only thing to note is json export in v3 will have slightly different structure with posts meta fields as separate.
- Creates new post_meta schema/table with 8 fields (2 meta_* , 3 twitter_* and 3 og_*)
- Update relations between post and post_meta table
- Update input/output serializers to keep existing API behavior
- Avoids new entry in post_meta table for post where all meta fields are null
- Keeps the current fields API param behavior
- Handles migration of existing posts to new table structure
- Updates importer/exporter to work seamlessly with table changes
no issue
- v0.1 is ☠️ so the access/refresh token based auth is no longer used
- removed all code related to the `accesstokens` and `refreshtokens` tables
- removed all `passport` related dependencies as it's no longer used
no issue
- v0.1 is ☠️ so there's no longer any use of client auth
- removes all code related to `clients` and `client_trusted_domains`
- noops the "add backup client" migration in 1.7 because the referenced fixture no longer exists causing migrations and consequently all regression tests to fail
no issue
- we used to redirect paths such as `/logout/` and `/signin/` to the admin but they are no longer desired
- with the introduction of members these URLs can be confused with front-end member related actions
- we want to be able to optionally "turn off" redirects to the admin to help mask the admin url when it's configured to be separate to the front-end
no issue
- @tryghost/url-utils was bumped to 0.3.1 which fixed admin redirects returning relative rather than absolute URLs
- updates tests that were expecting relative URLs rather than absolute URLs
