This package contains the business logic for the sending of mention
report emails, it could eventually be included in the webmentions
package I think, but has been kept separate for now in favour of
smaller packages.
refs https://ghost.slack.com/archives/C025584CA/p1678886661494989?thread_ts=1678886465.260379&cid=C025584CA
- if we're running a prerelease, our usual format is `<major>.<minor>.<patch>-pre.<commit hash>.<build>`
- if you wanna see what commit it was built on, you have to copy and
paste the hash into a GitHub URL
- this provides an easier route to the commit by detecting if the
version is our special format and links direct to GitHub if so
Because there is no guarantee about a daily job running exactly once a
day, we need to store the last time that the email was sent, so that we
can refrain from sending one if it's been less than a day since the
last.
A setting has been used for this as we don't currently have a pattern
for it, we might want to consider moving this to some kind of cache
based solution in future. This has been added as a core setting so that
we don't expose it via the API.
The setting is stored as a number to allow us to store value as unix timestamp.
---------
Co-authored-by: Rishabh <zrishabhgarg@gmail.com>
- we use ES6 `import` for all other imports so this standardizes the
React package to also use import vs require
- merged with other imports from the react package if present
Refs https://github.com/TryGhost/Team/issues/2612
- the recent posts were used to link to the editor, now they're linked to their analytics page
- now that we have an analytics screen for each post it makes sense to link to that screen where possible
refs https://github.com/TryGhost/Team/issues/2612
- member event feeds previously had links to posts that opened the
front-end post URL in a new tab
- now that we have an analytics screen for each post it makes sense to
link to that screen where possible because it allows drill-down into
site performance
refs https://github.com/TryGhost/Toolbox/issues/524
- The 'mediaInliner' beta flag is not used for anything anymore, so there's no need to keep it around. The only surface of the feature is the `POST /db/media/inline` endpoint that will be used through internal tooling mostly and won't be accessible through the Admin UI.
refs https://github.com/TryGhost/Toolbox/issues/524
- We no longer need the UI of any kind for the media inliner feature as
the inliner endpoint will be used mostly for internal purposes through
automated tooling
- This reverts commit 901485c47b.
refs https://github.com/TryGhost/Toolbox/issues/524
- The endpoints is for internal (non-documented) usage at the moment and is fine without the labs flag.
- This should allows us to test the inlining on production sites sooner
fixes https://github.com/TryGhost/Team/issues/2725
- Added to emails if labs flag enabled, comments enabled and comment CTA button enabled
- Links to comment section
- Design and styling not added yet
fixes https://github.com/TryGhost/Team/issues/2724
This change also includes new snapshots for email sending (similar for email previews, but this time for the real emails to make sure we catch changes).
fixes https://github.com/TryGhost/Team/issues/2705
- Added showPostTitleSection to newsletter model in admin
- Wired up UI to admin model so it saves to the database
- Implemented showPostTitleSection in newsletter preview and added some
minor temporary css styling
- Implemented showPostTitleSection in newsletter template in backend,
and added some extra CSS styling to fix spacing
no issue
When using `getLazyRelation` on an optional relation that is not set, it
will return a newly created model instead of a model from the database.
- Adds a new require option to `getLazyRelation`, that throws an error
if the relation is not set (off by default to match existing use cases)
- This caused a bug (not visible because we always pass a newsletter id)
in email previews, where when the newsletter id was not explicitly set,
it would use `newsletter = (await post.getLazyRelation('newsletter')) ??
(await this.models.Newsletter.getDefaultNewsletter());`, which always
returned the first one, and could return a newly initiated newsletter
with all properties set to undefined.
- Some page snapshots are altered by this, because the usage of
`getLazyRelation` on a post no longer sets the email relation to some
new model.
refs
https://www.notion.so/ghost/Marketing-Milestone-email-campaigns-1d2c9dee3cfa4029863edb16092ad5c4?pvs=4
- When milestones will be activated we would send out emails to users
that are way above the achieved milestone, as we didn't record
milestones before
- The plan is to implement a 0 milestone and don't send an email for
achieving those and also add all achieved milestones in the first run
until a first milestone is stored in the DB, then increment from there.
- This change takes care of two cases:
1. Milestones gets enabled and runs initially. We don't want to send
emails unless there's already at least one milestone achieved. For that
we add a 0 milestone helper and add a `initial` reason to the meta
object for the milestone event, so we can choose not to ping Slack and
also disable email sending for all milestones achieved in this initial
run.
2. All achieved milestones will be stored in the DB, even when that
means we skip some. This introduces the `skipped` reason which also
doesn't send emails for the skipped milestones, but will do for
correctly achieved milestones (always the highest one).
- Added handling for slack notifications to not attempt sending when
reason is `skipped` or `initial`
The service.js files are rarely unit tested because they are
essentially glue code which acts as a singleton and doesn't use
dependency injection, this lil cocktail makes it difficult to stub
dependencies, as well as to call the init method more than once in a
test suite. This change should give us improved unit test coverage
