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
- With the package being out of TryGhost/Ghost codebase the paths have changed and needed to introdude a concept of "fixtures" for the package to be able to funciton independently
refs https://github.com/TryGhost/Toolbox/issues/292
- This dependency is needed for the package to function properly. Have pinned it to a lower major than is currently available to avoid a unnecessary rabbithole of dealing with breaking changes
refs https://github.com/TryGhost/Toolbox/issues/292
- There's a need to reuse these utils in the version mismatch notification service. Having loads of tightly coupled dependencies makes it super hard to rip out this module for reuse
- It's a groundwork for extraction of the email-utils package
- Rewrote the unit tests that were written for these utils previously - they weren't testing anything useful. The goal of this util is to generate specific content based on provided data and available templates - now the tests do test those specific things, not the mailer itself!
- this is a small part of a bit of cleanup of our test files
- the goal is to make the existing tests clearer with a view to making it easier to write more tests
- this makes the test structure follow the codebase structure more closely
- eventually we will colocate the tests as we break the codebase down further
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.
- trying to call new RequestNotAcceptableError with a variable triggers a lint warning in newer versions of eslint-plugin-ghost
- this workaround is worth it for the safety of not allowing single strings to be passed in!
- this middleware block is used in v4 but not in v5
- we want to remove it and then rename handleJSONResponseV2 so that we have one single consistent error handling block
refs https://github.com/TryGhost/Toolbox/issues/292
- The version notification data service serves as data manger for version compatibility service
- There's not much logic mostly fetching data from proficed services and filtering/serializing it into a needed format
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
- There's a need to distinguish different types of RequestNotAcceptableError erros by their code. The code is also having an instructional name to give it more explicit utility (nice clue for a developer seeing the error)
refs https://github.com/TryGhost/Toolbox/issues/292
- This middleware is meant to deal with version missmatch erros and call a service that does all the business logic. Having this handling in a separate module allows for thisngs to be loosely coupled
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 :)
