refs https://github.com/TryGhost/Team/issues/1719
- creates scripts injected for portal/search/comments using new config format
- adds `data-styles` to search/comments script for adding external styles URL
refs https://github.com/TryGhost/Team/issues/1719
- switches default CDN from unpkg to jsDelivr for better reliability
- current config for frontend apps doesn't allow easy switching of CDN for frontend urls
- allows easy switch of base CDN for frontend apps via config
- fixes double use of version string in the config
- extends config to include url needed for loading styles for frontend app instead of hardcoded urs
- since we've turned the repo into a monorepo, the `yarn main` scripts
have lived in their original place under `ghost/core` package.json and
Gruntfile.js
- for one, we want to remove grunt because it's terribly old and our use
is hacked together
- secondly, `yarn main` applies to the monorepo + submodules as a whole,
and not just the Ghost core folder
- this commit extracts the functionality into yarn scripts in the
top-level and removes the dependency that was required
refs https://github.com/TryGhost/Team/issues/1709
- New event type `comment_event` (comments and replies of a member in the activity feed)
- Includes member, post and parent relation by default
- Added new output mapper for ActivityFeed events
**Changes to `Comment` model:**
* **Only limit comment fetched to root comments when not authenticated as a user:**
`enforcedFilters` is applied to all queries, which is a problem because for the activity feed we also need to fetch comments which have a parent_id that is not null (`Member x replied to a comment`). The current filter in the model is specifically for the members API, not the admin API (so checking the user should fix that, not sure if that is a good pattern but couldn’t find a better alternative).
* **Only set default relations for comments when withRelated is empty or not set:**
`defaultRelations`: Right now, for every fetch it would force all these relations. But we don’t need all those relations for the activity feed; So I updated the pattern to only set the default relations when it is empty (which we also do on a couple of other places and seems like a good pattern). I also updated the comments-ui frontend to not send ?include
refs https://github.com/TryGhost/Team/issues/1717
- Updates last_commented_at and last_seen_at (only once a day)
- Used the LastSeenAtUpdater, so we can combine updating last_commented_at and last_seen_at in one query + used same pattern
- Updated comments service to await emails in order to make E2E tests more stable (as we don't have any method to await emails and test emails otherwise). This removed the email sending logic from the `onCreated` hook of the model.
fixes https://github.com/TryGhost/Team/issues/1718
- Text content of report emails still had some placeholder text
- Converts HTML comments to TXT to include in the TXT version of the email
- Added support for Regexp matchers in the email mocker
- Added tests to check if the email content is in the new comment/report emails
refs https://github.com/TryGhost/Toolbox/issues/354
- these READMEs were migrated over from when each package was in a
different repo
- they also assume you're going to be publishing the packages because it
mentions install instructions
- only a few of them contain custom content
- this commit deletes the majority of these files because they're now
not useful
- any that contained other instructions have been cut down
refs https://github.com/TryGhost/Team/issues/1688
* Added missing/failing tests
* Refactored comments BREAD into service
* Ensured member_id is not writable, it should come from auth only
* Ensured one cannot reply to a reply
* Ensured the parent_id is not writable on edit
refs https://github.com/TryGhost/Toolbox/issues/354
- these repository links made sense when they were in different repos
and published to NPM but we don't publish these packages any more
- this commit deletes those keys from the files
- these were copied over during the monorepo conversion but we're not
going to be publishing these packages so the top-level LICENSE file
covers all packages here
- we had this working in the Ghost repo before switching to a monorepo
- this commit adds a `setup` script to the root package.json so we can
maintain the functionality
- these scripts are useful for just trying to fix your repo when
node_modules is playing up
- as we now have a monorepo, they should be lifted up to the root and
not hidden in the ghost package
refs https://github.com/TryGhost/Toolbox/issues/357
- Adds support for persisted one off offloaded (worker thread) jobs
- To try them out run Ghost instance in "testmode" and shoo a request like so: `curl http://localhost:2368/ghost/api/oneoff/graceful-job` - this starts a one time job from graceful-job script (can only ever be executed once on the Ghost instance)
- Job's progress and runtime details are persisted in `jobs` table
- To play more with one off jobs use `addOneOffJob` method available on jobsService
refs https://github.com/TryGhost/Toolbox/issues/357
- Job persisted in the database need to track job's execution status such as completion, failure, execution start and end times. This changeset allows to hook into job/bree lifecycle to track job's progress.
- NOTE: only supports "offloaded" jobs at the moment. Support for "inline" jobs will be added once there's a clear usecase for it.
- The "started" status and "started_at" timestamp are assigned to a job at the moment when the worker thread is created inside of bree
- The "finished" status and "finished_at" timestamp are assigned to a job when a "done" event is passed from the job script (NOTE: using process.exit(0) will not trigger the "finished" state")
- The "failed" status is assigned when the job execution is interrupted with an error
refs https://github.com/TryGhost/Toolbox/issues/357
- One time jobs need a storage mechanism to be run only ever once.
- Field notes:
- `id`, `created_at`, `updated_at` - standard Ghost fields
- `name` - unique name of the job, could also be used with prefixing to identify certain type of job (e.g.: backup-bob-2022-10-16, backup-sam-2023-01-13 identifying backup jobs run by users)
- `status` - 'started' | 'finished' | 'failed' | 'queued' (need to identify when the job is in progress, done, added to the execution queue, or errored)
- `started_at` - when the job started execution
- `finished_at` - when the job successfully finished execution
closes https://github.com/TryGhost/Team/issues/1684
**Migrations:**
- Added report permissions (fixtures + migrations)
- Dropped reason field in reports (no textarea in reports in V1)
- Dropped nullable from comment_likes.member_id (can't be null)
- Added SET NULL/CASCADE foreign keys for comments related tables(*)
(*):
fixes https://github.com/TryGhost/Team/issues/1687
refs https://ghost.slack.com/archives/C02G9E68C/p1658217288591369
This commit adds support for `SET NULL` foreign keys in schema and migration helpers + also fixes the foreign keys for the comment_reports, comment_likes and comments tables.
- When a member is deleted, we **do** want to keep their reports (SET NULL)
- When a member is deleted, we **do not** want to keep their likes (CASCADE)
- When a member is deleted, we **do** want to keep the comments (SET NULL)
**Changes:**
- Added report API: `POST /members/api/comments/{id}}/report/`
- Sends an email to the owner when a comment is reported
- Saves a report to the database (not used for now, but might be useful later)
refs https://github.com/TryGhost/Toolbox/issues/357
- This is a scaffolding for what will become a one off job scheduling mechanism. The aim is allowing to run jobs which can be only ever be run once in the lifetime of the instance - persisting through restarts.
refs https://github.com/TryGhost/Toolbox/issues/357
- In upcoming iteration job manager will need "models" fully initialized to be able to persiste one time jobs. This bit of code of in a bad place as it initialized (through require) the job manager without having models module initialized first.
- The change moves that code from a bad to less bad place (wasn't able to think of any better location for now). Checking for `server:testmode' config in job initialization has a little bit of a smell, but don't think it's super critical. Could be improved if a better structure appears in the future!
- we're going to be pinning all dependencies within the monorepo
- this shouldn't change anything anyway because we're using the same
version across all packages
- we keep seeing a lot of random failures from CI due to the Posts
Content API
- I think it's because of the Ghost boot + number of fixtures we load,
which sends us over our 10s threshold
- let's see if 15s resolves that
