no issue
- The helper allows generating HTML needed to cancel or continue the member's subscription depending on subscription state.
- Added public members endpoint to allow updating subscription's `cancel_at_period_end` attribute available at: `PUT /api/canary/members/subscriptions/:id/`
- Added client-side hook to allow calling subscription cancellation. Allows to create elements with `data-members-cancel-subscription` / `data-members-continue-subscription` attributes which would call subscription update.
- Updated schema and added migration for `current_period_end` column
- As discussed we only add a single column to subscriptions table to avoid preoptimizing for future cases
- Added {{cancel_link}} helper
- Added error handling for {{cancel_link}} when members are disabled
- Added test coverage for {{cancel_link}} helper
- Bumped @tryghost/members-api version to 0.10.2. Needed to use `updateSubscription` middleware
- Bumped gscan to 3.2.0. Needed to recognize new {{cancel_link}} helper
no issue
- This includes the interface change for members-api constructor - now accepts the member's model instead of proxy methods. These methods have been moved ton @tryghost/members-api in favor of using the model directly (ref: https://github.com/TryGhost/Members/pull/105)
- Moved error handling from the service layer to controller
- Bumped @tryghost/member-api package to 0.10.0
no issue
- This test was checking for a very edge casy scenario (blog timezone change when scheduled date for a post changes at the same time). It's been hard to keep it maintaned so had to go.
no-issue
Our function for determining cors options created a new instance of URL
without wrapping it in a try/catch which meant any failures to parse the
URL bubbled down as a 500 error.
500 errors are commonly used for alerting at the infrastructure level,
and this error is definitely one caused by a badly configured client, so
we wrap the construction and crap out with a Bad Request Error (HTTP
400) if it fails.
no-issue
This name `login` was misleading as this middleware didn't login
members, that was handled by the `authentication` middleware,
specifically `exchangeTokenForSession`
no issue
- Secondary navigation means most nav concepts are supported, e.g. header & footer, or left & right
- The UI is added separately, this PR adds supporting concepts:
- make sure the default value is an empty array
- add support in the API (v3 only)
- add handling in the navigation helper
no issue.
- "[Test]" being appended (at the end of) the test email subject made it hard to scan for test emails. This fixes it by prepending "[Test]" to the subject.
refs https://github.com/TryGhost/Ghost/issues/10062
- When content gating is in place a lot of times both `html` and `custom_excerpt` fields on posts/pages are empty and the output of `{{excerpt}}` helper is also empty. We do return an `excerpt` property as a part of post resource which can serve as a safe fallback for when the above fields are not filled. It massively improves the experience of using the helper with gated content
- Refactored nested ternaries to be more readable
- Added fallback to excerpt property when HTML is hidden from members
- Removed note about the review of excerpt helper
- Added test case for 'excerpt' property
Adds transaction support to `fetchPage` method. This is needed to be able to count members during the post publish transaction.
This is the next iteration over initial quick-fix: 90905b0212
* Added transaction support to pagination plugin
- This support is needed to be able to use `fetchPage` method in transactional context (example usecase was counting members when publishing post for emails)
* Passed transaction related options during email creation
- Without this SQLite would hang in a transaction and eventually timeout
* Updated parameter name for consistency
no issue
We changed `reschedule` event to trigger adapter's `unschedule` and `schedule` methods since we now generate separate tokens(urls) for consistency as two different url(token) is needed to complete the reschedule functionality.
no issue
The default scheduling generates a known, independent URL for publishing a resource. In case of resource being rescheduled or unscheduled, the adapter expects the the same URL to remove/update existing jobs. The URL includes a JWT token for API auth which is calculated from post model and appended to URL.
There was a bug in token generation which meant If we go to update or delete the job i.e. unschedule a post then a new token is used which means the existing scheduled job cannot be removed. This PR:
- removes issued at (`iat`) timestamp from token generation which lead to a different token being generated for same payload
- Fixes timestamp being used for URL calculation from resource model
no issue
- the schedules controller wraps the post creation in a transaction
- we need to pass that transaction through to all other queries, especially on sqlite where a non-transaction query inside a transaction will lock up because there's only 1 connection available
- updates our model method calls to pass through the transaction options
- switches the members service `list()` call to a direct model `findAll()` call to avoid going through our pagination plugin because the raw knex query does not respect the transacting option
no issue
- When having following routes.yaml configuation and theme runing API v3:
routes:
/:
data: page.home
template: home
- There was an internall error in meta layer: `Cannot read property 'website' of undefined` which was caused by not being able to read primary_author on a fetched page
- We need to include authors and tags for pages, the same way we do for posts to prevent this error (as they should have identical properties from meta layer perspective)
no issue
- additional migration for the column added since the last 3.1 beta release to allow beta upgrades without rollbacks
- will be a no-op for upgrades from 3.0 as it's covered by `3.1/05-add-emails-table.js`
We want to allow admin users to trigger a retry of failed emails without having to go through the unpublish/republish dance.
- fixed resource identifier in email permissions migration so email permissions are added correctly
- added new email permissions migration so that beta releases can be upgraded without rollback (will be a no-op for any non-beta upgrades)
- added `/emails/:id/retry/` canary Admin API endpoint
- follows same URL pattern as theme activation
- only triggers mega service retry endpoint if the email has a `'failed'` status
no issue
- In order to keep site/app.js module tidy and less coupled with members module we need to extract some of the functionality where it belongs conceptually
- Added "members enabled check" middleware to stripe webhook endpoint
- Reshuffled members middleware so that siteApp is in control of mounting points. This is meant to be a more explicit way to see which endpoints are being handled by members middleware
- Extracted member-specific public file middleware
- Unified use of `labs.member` alias method. Done for code style consistency
- Added basic members' test suite. This is a base we could work from when more modifications are needed
- Removed route handler for unexisting members file "members-theme-bindings.js". Calling this route otherwise causes a 500. Looks like a leftover from 49672a1e4d
no issue
- a 401 is received from Mailgun when invalid credentials are used but the default error message of "Forbidden" is not particularly useful
- intercepts "Forbidden" and swaps it for "Invalid Mailgun credentials" to be more user-friendly
