no-issue
Until now, we've used ghost@siteurl.com as the default from address for system emails, like user invitations and password resets. This was fine, because all system emails were going to people who would interact with "ghost" the app in some way, so the naming made sense.
Now we're introducing members, which will send emails on behalf of of the site owner, to their readers. If all goes to plan, they should be able to set a custom from address, however our default mail config will still be the fallback if no other value is available.
If you run "magazine.com" and you send someone a link to "login to magazine.com" then it's pretty weird for that email to come from "ghost@magazine.com" - so this PR changes the default value from ghost to noreply for an equally generic, but less opinionated default.
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
You can now use `data-members-success` and `data-members-cancel` on any
element which also has a valid `data-members-plan` attribute to set the
cancel and success redirects for stripe checkout.
The value will be used similar to how a `href` attribute would be.
e.g.
On a page https://site.com/membership
An attribute of "/success" would redirect to https://site.com/success
An attribute of "success" would redirect to https://site.com/membership/success
An attribute of "https://site.com/whatever" would redirect to https://site.com/whatever
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
ref 6bbe7bb3d4
- This value is no longer being set on the client side and doesn't serve any purpose. The logic should rely on payment processors being configured instead
no issue
- Moved default_content_visibility out of labs as we should be extra careful with what is exposed in the labs + it doesn't really belong there.
no-issue
This allows the theme developer to drive the different flows based on
the data-members-form attribute. If the attribute is empty or blank, the
default "signin" will be sent.
no-issue
This adds basic templates for "signup"/"signin"/"subscribe" types for
the magic-link email template. It also adds the action query parameter
to the link so that clientside js can handle the different states.
no issue
- Added 'labs' flag settings test
- Added test for default_content_visibility flag
- Default post's visibility takes into account values set in default_content_visibility setting
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
- updates usage of `htmlRelativeToAbsolute` to avoid unnecessary duplication of "home" url fetching (the UrlUtils instance already has that information)
no-issue
This maps the stripe_info property to the MemberStripeInfo model, so
that we can update the member model, and correctly add/edit rows in the
members-stripe-info table.
no-issue
This will be used to store stripe specific information for members
customer_id has a max length of 255 https://stripe.com/docs/upgrades
member_id is not unique as we cannot ensure that a member doesn't have
more than one customer object associated with them. e.g. if they signup
twice, or if they cancel, and signup again, creating a new customer.
We probably won't handle this case to begin with, but we will keep the
data intact.
- Currently, we create a request ID for internal use if one isn't set & this is used in logs
- If a custom request ID is set via X-Request-ID header, this gets logged, however, we don't return this with the response
- Means that a custom ID gets lost on the way back out, and makes tracing requests through a system trickier
- This change ensures that if X-Request-ID is set on the request, it is also set on the response so that requests can be properly traced
- It's easy to set this in e.g. nginx so that the feature becomes available - Ghost doens't need to do this
- Note: also split request id handling out into new middleware
no-issue
This also adds a basic check before handing of to the members-ssr
module, this should make logs a little less noisy and only log warnings
if a token was passed and that token was invalid/incorrect.
