- because of how the npm scripts were set up, we were running the full
Admin integration tests during the unit tests phase of CI
- this commit renames the majority of `test` to `test:unit` in the
package.json files, and aliases `test` to `test:unit`
- special packages like Admin have no-op'd `test:unit` scripts so we
don't end up running its tests
- we shouldn't need individual LICENSE files because these packages
won't be published, so the top-level one applies
- also cleaned up README files to remove mentions of Lerna monorepos and
install instructions
refs https://github.com/TryGhost/Toolbox/issues/354
- set packages to `private: true`
- removed repository link - these packages won't be published so this
link won't be seen anywhere
- removed `publishConfig`
refs https://github.com/TryGhost/Toolbox/issues/292
- Providing user-defined Integration name instead of API client's UserAgent gives a lot more control to instance administrators identifying which integration is being used incorrectly.
- It's best practice to create an Integration with a set of API keys per API client - which should be enough to identify an outdated one.
refs https://github.com/TryGhost/Toolbox/issues/292
- The version-notifications-data-service did not resolve correctly after it was removed from it's package.json. It should have been declared here from the get go!
refs https://github.com/TryGhost/Toolbox/issues/292
- The service used to take in a whole bunch of functions as parameters and did expect the client to know about the "version-notifications-data-service" which is not necessary and make the constructor API a notch complicated
- Putting in the data service initialization internally allows for the client to pass in less parameters and know less abou the internal working of the service - way easier to use!
refs https://github.com/TryGhost/Toolbox/issues/292
- When the handler recognizes a Zapier client it should send an email using Zapier-specific template with instructions more suitable for Zap failure
refs https://github.com/TryGhost/Toolbox/issues/292
- The html/text emails is a desired system that's used in Ghost core and should be reused with version mismatch notification emails too.
- Currently there's only one template defined "generic-mismatch" and the original file for it can be found under /templates/generic-mismatch.html
- If we need to distinguish user agents we can addd more templates to the `/templates/` folder
refs https://github.com/TryGhost/Toolbox/issues/292
- The audience of the notification emails for version missmatch could be less technical - site owneres are usually creators not programmers. Not using complex technical details in the email subject/body should make the incompatibility more approachable to deal with.
refs https://github.com/TryGhost/Toolbox/issues/292
- There can be multiple users in the Ghost instance that should be notifiied about version mismatch. Following the logic of the security notifications these are users with 'Owner' and 'Administrator' roles. To have the most up to date list of the emails to notify the emails fetching was made dinamic and is now passed in as a 'fetchEmailsToNotify' function.
- Also fixed the subject of the email to match the final copy
refs https://github.com/TryGhost/Toolbox/issues/292
- The standard sendEmail function used in Ghost accepts three non-optional parameters: to, subject, and html. Have extended the usage with these three required fields
refs https://github.com/TryGhost/Toolbox/issues/292
- Super happy path scenario which handles sending information with some basic incompatibility information
- It's meant to be built up upon! More to follow :)
