refs: https://github.com/TryGhost/Toolbox/issues/595
We're rolling out new rules around the node assert library, the first of which is enforcing the use of assert/strict. This means we don't need to use the strict version of methods, as the standard version will work that way by default.
This caught some gotchas in our existing usage of assert where the lack of strict mode had unexpected results:
- Url matching needs to be done on `url.href` see aa58b354a4
- Null and undefined are not the same thing, there were a few cases of this being confused
- Particularly questionable changes in [PostExporter tests](c1a468744b) tracked [here](https://github.com/TryGhost/Team/issues/3505).
- A typo see eaac9c293a
Moving forward, using assert strict should help us to catch unexpected behaviour, particularly around nulls and undefineds during implementation.
refs https://github.com/TryGhost/Toolbox/issues/500
refs https://ghost.notion.site/Data-Types-e5dc54dd0078443f9afd6b2abda443c4
- There current notification logic for incompatible integrations did not take into account the source of the trigger, which might have been causing emails to instance owners that did not ever set up custom integration - so they had nothing to fix.
- The "internal" and "core" integrations are maintained/controlled by the Ghost team, so there should never be a notification going out to the instance owner about possible incompatibility in the code they do not control.
- Along with changed updated the unit test threshold in the packages that were touched to 100%. As that's the standard for all new packages.
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 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 :)
