no issue
- The aim is to achieve 100% unit test coverage for servies and small modules. This change covers few more bases brining limit-service's module coverage from 80% to 94%.
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/588
- The limit service can now be initialized with a config which has a 'maxPeriodic' key identifying it's a special type of limit taking subscription cycles into account
- Example configuration can be found in the included unit tests
refs https://github.com/TryGhost/Team/issues/588
- This is a step 1 in the introduction of email limits. Next step would be allowing this limit to support "periodical limit checks"
refs https://github.com/TryGhost/Team/issues/599
- There are cases when there'a a need to reload limits with a new set of configuration. For example, when Ghost is run in a test environment is a soft reboot is done
- Resetting previous value of limits avoids having conflicting state after multiple calls
refs https://github.com/TryGhost/Team/issues/510
- {{max}} and {{count}} variable usage was not covered but had valid usecases in the library client's, so considered to "document" them through tests
- For more context these variables are available in custom `error` templates that are provided with each limit
refs https://github.com/TryGhost/Team/issues/597
- When the library is used on a client without a DB connection (e.g. frontend client running in a browser) the library needs to expose a way to override count queries.
- The way these can be used is giving a count based on a HTTP request or some other data provider
- Example use with max limit like "staff" would be loading the limit servcie if following way:
```
const limitService = new LimitService();
let limits = {
staff: {
max: 2,
currentCountQuery: () => 5
}
};
limitService.loadLimits({limits, errors});
await limitService.checkIsOverLimit('staff')
```
refs https://github.com/TryGhost/Team/issues/597
- To be able to transpile the library for different runtimes (make it polymorphic) had to get rid of dependencies that were not compatible with ES Modules
- By making errors an injectable constructor option it removes the depencency and allows to transpile the library for multiple targets
- The `errors` option is now a required parameter for `loadLimits` method. It errors if it's missing (error message copy inspired by content api error 69fcea0582/packages/content-api/lib/index.js (L21))
refs: https://github.com/TryGhost/Team/issues/510
- Ghost config always uses camelcase. This was incorrectly implemented with snake case originally
- Swap to use camelCase by default, which is desirable, but support both
- It's really easy to support both in the loader and isLimited check, so we do this to stop ourselves tripping on this later
