no issue
The email data attached to a post when published with send email flag was not filtered on member access, and picked up the whole member list for email data. This resulted in incorrect data stored in emails table even in case of paid-members-only publish, and also incorrect count of "emails sent" being displayed on Admin.
NOTE: The actual emails being sent are still gated by member access, so no emails were sent to anyone without access, this only affected the associated email data and count. Also, the fix here will show correct email sent status for any future post, but will still show incorrect data for any already published posts as the email data in DB is already wrong and will probably need a migration
no issue
- After investigating effects of allowing editing email there were no significant blockers found, so there is no reason not to allow editing this field
no issue
- This field is usefult when importing from external sources.
- The date format should be compatible with one used internally by Ghost which is RFC 2822 compliant format
refs https://github.com/TryGhost/Team/issues/243
- uses `member.toJSON()` to add a computed `avatar_image` property
- if the member has an email address and gravatar is not disabled then we generate a gravatar url using the `?d=blank` parameter to return a transparent image if the member's email has no gravatar
no issue
- 3.6.0 contained incorrect references in the `schema.js` file for the `members_label` table that was added in that version. On MySQL knex created a foreign key constraint for that reference which stopped member labels from being createable
- this fixes the schema file and has a migration to drop and recreate the table. Knex handles removal and addition of foreign keys during table drop/create
no issue
- When importing through CSV we should remain the defaults of 'subscribed' fields (`true` at the moment), unless it is explicitly set to `false` or `FALSE` (the latter uppercase value often comes from scpredsheets)
no issue
- some errors weren't being reported because they were being passed to
Sentry before our middleware could populate the error information
- this commit inserts the Sentry middleware into these steps
no issue
- when `servePublicFile` middleware serves an image it resulted in a "Cannot set headers after they are sent to the client" error because `next()` was erroneously called for successful requests which then tripped the `prettyUrls` middleware which tries to perform a redirect
- only calling `next()` when an error is present allows errors to be picked up by later middleware but successful requests end in the `servePublicFile` middleware
no issue
* Updated sendEmailWithMagicLink syntax
* Updated label name selection from theme
* Updated migration version for labels
* Added labels to export/import of members
* Added member labels sanitization for case-insensitive duplicates
* Fixed tests
* Fixed label serialization bug on import
* Bumped @tryghost/members-api to 0.15.0
* Fixed lint
* Cleanup
no issue
- Allows for syntax like `{{#has visibility="paid"}}` to be used on Content API resources (posts, pages, etc.)|
- The need for this change cropped out from being able to distinguish paid/member-only/public posts in member-enabled themes.
no issue
We missed handling `undefined` values for fields during csv export for memebrs, which causes csv entries as `undefined` for fields that don't exist. It also added need for extra handling of `undefined` entries during csv import. This PR fixes the bug by properly handling empty/undefined values in export
no issue
- When new Ghost instance is initialized "Complimentary" plan doesn't have to wait for the rest of plans to be configured.
- Without configured plans the admin would still be able to assign "Complimentary" plan to members or import same kind of members.
- There is no error handling at the moment when plan initialization fails, that's why it was very confusing when all of the sudden it wasn't possible to create a member record
closes#11589
- `findOne` method in destroy method was usinng wrong options object (unlinke read method id comes from frame.options not frame.data) thus this was causing 404 errors
- The filename is returned to be able to fetch the backup on demand
- Wasn't able to limit exported tables as exporter doesn't support such functionality
no issue
- serving of our public asset images was broken
- we were reading the binary file in as a string so we could do url transforms, this meant data was lost/corrupted and browsers could not display the served data
- we were using the wrong mime-type for pngs which meant browsers were triggering downloads rather than displaying images (at least when accessed directly)
- updates uses of `servePublicFile` to have the correct png mimetype
- adjusts `servePublicFile` to treat any mime type starting with `image` as a binary file, passing the file directly through express using `res.sendFile` and skipping the in-memory content caching which is mostly only useful for text files with URL transforms
no issue
- When importing large batches of members we should not allow for unlimited amount of parallel requests created as this might lead to connection pool problems and reaching API rate limits (for example Stripe API is limited to 100 req/s)
no issue
- if a request was sent for an resized image URL that didn't contain a
file extension, the code would eventually end up throwing a 500
- this commit checks for this case and returns a 404
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
