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
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
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
- There's a need to calculate when the last period has started to be able to generate correct counting queries for the "maxPeriodical" limit
- It operatest on ISO strings as an input and output in UTC timezone to take timezone calculations out of the equation
- Refer to inclucded unit tests for example calculations
refs https://github.com/TryGhost/Team/issues/588
- This is a scaffolding for a new limit type which should allow to check limits based on periods (for example related to billing, subscription cycles)
refs https://github.com/TryGhost/Team/issues/588
- This is by no means an thorought test coverage but ensures the basics work and provides examples of how the limit should be used. To be continued :)
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"
no issue
- I was a little confused seeing an empty object in the config moduele - `customThemes: {}` and initially thought we could get rid of it to reduce the amount of code. Afte quick dig found out that there's a purpuse behind it being there! It's an allowlist of the properites that can be defined within the limit service
- Added notes to clarify the usecase and avoid ambiguity in the future
no issue
- this Utils repo contains libraries, whose dependencies should not be
pinned in order to reduce multiple versions of the same package
appearing for consumers
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
- Flag limits are impossible to check if they are "over a limit already" as they are just that - on/off flags. Therefore it should be directly noted that the method is there to keep the "Limit" interface and not be relied upon
refs https://github.com/TryGhost/Team/issues/587
- Improved description and provided example use of error message template variables that are available for "MaxLimit" types of limits
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))
