- these packages are split apart for local development, but will be
bundled into Ghost when publishing
- therefore, these packages won't be published so we are resetting the
versions to make them cleaner
refs https://github.com/TryGhost/Toolbox/issues/354
- this commit turns the Ghost repo into a monorepo so we can bring our
internal packages back in, which makes life easier when working on
Ghost
fixes https://github.com/TryGhost/Team/issues/1697
- Don't send a notification email when you reply on your own comment
- Added some tests for comment emails (requires some async waiting, maybe we can improve this in the future)
refs https://github.com/TryGhost/Team/issues/1693
- The comments section needs to know the access settings for comments
- Updated the comments helper to also double check access settings (comments enabled + member has access to the post)
no issue
- used for an ongoing react based editor experiment
- by exposing `editor.url` in public config it lets Admin dynamically fetch the external module and allows for independent releases of the editor without needing to have a full Ghost release
- follows the same pattern as portal and comments
refs https://github.com/TryGhost/Team/issues/1686
- When the settings are updated with the `members_support_address` key present, it would always send a verification email
- Root cause is that the service failed to check if the email was changed or not. Due to a bug it always thought the email was changed, triggering the verification flow.
- The admin app will always send all the settings keys when changing some other value. This causes a lot of email verification emails.
- Added tests and email count checks in tests
refs https://github.com/TryGhost/Team/issues/1686
- When the settings are updated with the `members_support_address` key present, it would always send a verification email
- Root cause is that the service failed to check if the email was changed or not. Due to a bug it always thought the email was changed, triggering the verification flow.
- The admin app will always send all the settings keys when changing some other value. This causes a lot of email verification emails.
- Added tests and email count checks in tests
- these have been deprecated and undocumented for a long time so we can
now clear them up as `yarn main` and `yarn test ...` are the official
ways to do the same thing
- up until now, we've been running `grunt release` before publishing to
NPM or pushing the canary zip
- this command runs the production asset build and generates a zip
- this zip isn't used by the NPM publishing task because that does an
`npm pack`
- we only use it for the canary build, but this should be brought more
inline with the NPM process to make the gaps smaller
- this commit refactors the `grunt release` task to become a lot smaller
by removing the generated zip steps
- the expected workflow is now to just to an `npm pack`, which will run
the `prepack` task to generate a `.tgz` archive
- this should still respect `.npmignore`, so it'll just include the
files we expect
- the test of the canary workflow is being updated to handle this
- also cleans up a dev dependency that is no longer used, along with 2
imports
no issue
- The test adds clarity to how Content API handles 404 error where the resource was not found. The need came from a suspicion we do not handle this scenario well on production.
refs https://github.com/TryGhost/Ghost/issues/14983
The url field of tags is read dynamically from the url service, rather than
from the database. The lookup requires the id of the tag, which was missing
from the model when asking for explicit fields which didn't include id. By
adding the id as a default column to fetch, we know for sure that we will always
have the necessary data to read the url.
refs https://github.com/TryGhost/Team/issues/584
The current support email verification flow uses an API endpoint as verification URL inside the emails. This is a bad pattern, and also has the side effect that it shows a JSON error if something goes wrong.
To fix this, this commit updates the whole flow to use the same pattern as newsletters:
- You can update the `members_support_address` setting directly via the edit endpoint of settings.
- Changes to that (and future 'guarded' email properties) are blocked and generate verification emails automatically.
- When an email verification has been sent, the meta property `sent_email_verification` is set.
Other changes:
- Underlying, the implementation of email verificaton has moved from the (old) members service to the settings BREAD service. This makes it easier to add extra email addresses in settings later on that are not related to 'members'.
- Now you can update the `members_support_address` by updating the settings directly, so the `updateMembersEmail` endpoint has been deprecated and is mapped to the new behaviour.
- The SingleUseTokenProvider threw a `UnauthorizedError` error if a token was expired or invalid. Those errors are caught by the admin app, and causes it to do a page reload (making the error message and modals invisible). To fix that, I've swapped it with a validation error.
Future changes:
- Existing emails that have been sent 24h before this change is applied, still use the `validateMembersEmailUpdate` API endpoint. This endpoint has not been removed for now, to not break those emails. In a future release, we should remove this.
Changes to admin: https://github.com/TryGhost/Admin/pull/2426
refs https://github.com/TryGhost/Team/issues/1174
refs https://github.com/TryGhost/Members/pull/408
When logged out members navigate a site and want to interact with, for example
comments, they are redirected to the homepage after sign-in with the magic link,
this is disorientating, and means they then need to navigate back to the content
they were interacting with.
This change means that sign-in's will be redirected to the page from which they
were initiated, allowing a more streamlined flow for logged out members wanting
to add comments.
We've restricted the redirect to URI's which are on the same domain as the site,
and we also do a relative redirect, this is to ensure that a malicious actor does not
send magic links which redirect off-site and leak authentication details
closes https://github.com/TryGhost/Team/issues/1674
- The comped flag in Members API unintentionally stopped working when v3 API was dropped with the release of Ghost v5. The flag is deprecated but should be back-compatible for now - we don't want to break integratons like Zapier.
- To properly deprecate the flag we need to plan it's removal and start signalling about it through the version headers
Co-authored-by: Simon Backx <simon@ghost.org>
