refs https://github.com/TryGhost/Team/issues/728
- Passing only the necessary API endpoint function makes it easier to reason about what dependencies the UpdateCheckService has to deal with
- The instance initialization had to be moved insided the module's exports to resolve "models" module initialization failure
refs https://github.com/TryGhost/Team/issues/728
- Previous name was after the do-all-the-things mega module that have now become an "initializer" for the UpdateCheckService class. The unit tests are testing the latter, so the rename is a cleanup from the previous ways
refs https://github.com/TryGhost/Team/issues/728
- This is a continuation of the test coverage for the UpdateCheckService.
- Covers scpecial cases of notification processing within Update Check
- The refactor inside the update check service was a convenience to get rid or the Bluebird dependency completely. Also, some minor preventative code added to avoid errors from referencing undefined objects
refs https://github.com/TryGhost/Team/issues/728
- In additions to easier tracking of "this" context in the unit tests it gets rid of unnecessary Bluebird's "reflect" method which was making unit test dependent on Bluebird's specific Promise implementation
refs https://github.com/TryGhost/Team/issues/728
- This is a first step before moving update check code into an outside codebase.
- The aim is to have a self-contained module which could be unit tested and have a very clear API
https://github.com/TryGhost/Team/issues/663
- When there is no parameter passed at all it was a generic 'Cannot read property 'value' of undefined' message which wasn't helpful in recognizing what the actual problem was
- Have added additional guarding logic to throw a descriptive error
no issue
- I've discovered the "IncorrectUsageError" error was silently swallowed and the method returned a false positibe when an allowlist limit type was called with incorrect parameters
- In cases like this it's best to surface the real error early otherwise the logic might produce unsafe results!
refs https://github.com/TryGhost/Team/issues/662
- There is a need to check if any of the current limits are over limit in Daisy. This method is the simplest possible implementation to check if any of them are over limit
- Possible future iterations might include a list of names of the limits that have been acceded and their error messages
- The `checkIfAnyOverLimit` method should be treated as a starter to work up the complexity as needed
refs https://github.com/TryGhost/Team/issues/510
- There's a limited type of limit "names" supported by the limit service, so worth specifying them upfront. Also some limits are univerally aplicable like "flag" or "allowlist" and some are restricted like "max" and "maxPeriodic"
refs https://github.com/TryGhost/Team/issues/588
- The "emails" limit was added with recent changes and could be configured as either "flag" or "maxPeridoci" type of limit
- More docs on different types of limits to follow
refs https://github.com/TryGhost/Team/issues/588
- The `addedCount` parameter in `errorIfWouldGoOverLimit` method allows to specify a custom resource count that is about to be added. Example usecase is when we'd want to send a 100 emails and current limit is 99, and none have been sent so far. With previous implementation the check would've passed because it only checked for single resource that would be added through "+1". Current implementation allows to specify the amount of recources to be added
refs https://github.com/TryGhost/Team/issues/588
- The previous query was quickly copied from stats-service which was using incorrect table for the count
- Updated version sums up email_count values for emails in given period of time
no issue
- this commit adds the c8 dependency to the `package-json`, and prepends
it to the test alias so we can see the coverage in tests
- note: we're apparently already at 100%!
refs https://github.com/TryGhost/Team/issues/588
refs 6a1e722648
- date-fns proved to be unable to manipulate dates in consistent UTC format and was substitured with luxon in referenced commit. Removing it from tests for consistency
refs https://github.com/TryGhost/Team/issues/588
- date-fns proved to be unable to manipulate dates consistently in UTC timezone. Keeping all calculations and formatting in UTC is key to have consistency in dates when dealing in inter-system dates
- day.js also failed the test for correct UTC manipulation. See https://github.com/iamkun/dayjs/issues/1271 for example bug which prevents from consistent correct calculation
- luxon was the best option which WORKED. It's also a recommended successor for moment.js with really nice docs and active support
refs https://github.com/TryGhost/Team/issues/588
- This is a basic implementation which needs a review. Implemented it to fix failing tests in main
- Start date is expected to come formatted for DB's needs
no issue
- `Error` is very generic for this case and `IncorrectUsageError`
will populate the resulting error with the correct error code
- the `message` was pulled out to its own statement so we can avoid long
lines
no issue
- we're preparing the `package-json` lib to be extracted out of Ghost into
its own package so moving the initialization wrapper outside of the
folder makes the process a lot easier
