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
no issue
- These files kept generating a new ouput when trying to publish an unrelated package. Assuming the generation is orrect and commiting this just to get things out of the way (type definition files should not break any functionality)
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/597
- Before adding more parameters documented existing ones
- Created LimitConfig type definition to have easier look into the structure of limit conifiguration
refs https://github.com/TryGhost/Team/issues/587
- Documented common usecases such as:
1. initialization and configuration of limit service
2. usage of "max" types of limits
refs https://github.com/TryGhost/Team/issues/587
- There was no test coverage for MaxLimit's errorIfIsOverLimit check. Added basic test to make sure upcoming modifications don't break existing functionality
refs https://github.com/TryGhost/Team/issues/587
- The optional {max} passed as an option allows to override currently configured limit and do a theoretical new limit check. For example: check if the max limit will be exceeded if the limit changes (user changes plans)
refs https://github.com/TryGhost/Team/issues/587
- Having a JSDoc gives better intellisense when the class is instantiated and provides clues about what each parameter might be used for
refs https://github.com/TryGhost/Team/issues/587
- When the 'max' configuration is missing the instance of the class breaks when used unexpectedly. Followed similar approach to currentCountQuery check by failing fast in the constructor
refs https://github.com/TryGhost/Team/issues/587
- Test were missing for class initialization and around how the limit currently works.
- Before extending it's behavior throught its valuable to cover current functionality to not accidentally break anything
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
refs: https://github.com/TryGhost/Team/issues/510
- we need to make sure we take into account any invites that could be accepted at any time
- this counts all invites for non-contributor roles as well as all users who aren't contributors
- this should stop there being loop holes to inviting staff users
refs: https://github.com/lodash/lodash/issues/705
- Was seeing unexpected token = errors when using lodash templates in Ghost
- This is because we're setting template settings globally in this dependency and it affects every other user of lodash
- Using runInContext keeps this templateSettings change local to this lib
- Test proves that after requiring limits we can require lodash and have the default values again
refs https://github.com/TryGhost/Ghost/issues/12496
- `workerMessageHandler` option allows for custom worker message handling and allows to eliminate a need for loggers of any type inside of jobs.
- removing loggers from jobs solves file hanle leak which used to cause Ghost process to crash (see referenced issue)
refs #122
- In future changes there's a plan to add "inline" scheduled jobs, which would conflict current method naming.
- The amount of parameters in the methods was more than 3, so it made sense to transform them into an options object
- Scheduling still doesn't work for "inline" jobs. This should be solved as a part of upstream library (https://github.com/breejs/bree/issues/68)
closes https://github.com/TryGhost/Ghost-Utils/issues/118
- Custom error handling is needed to be able to override default bree
error handling logic.
- bree bump to 4.1.0 also fixed logging errors (object Object fix in
tests)
- The handler function receives two parameters. First contains an error
that has been thrown by the job. Second, job and worker metadata
no issue
- Provided more context about which type of job does what and introduced naming to be able to distinguish them
- The naming is still to be reviewed by peers
closes#117
- Having immediately executable offloaded jobs is necessary to be able to run usecases like: send batched emails now, or any other job that does not need to be scheduled
- Changed "simple" job timeout to make tests run faster
closes#119
- A future use-case which this feature caters for is allowing to migrate "post scheduler" to use job manager instead of managing scheduling itself
- removeJob method will be needed to allow "rescheduling" of the post
- this helps simplify the code and gets rid of Promise chaining
- apparently I can't easily use an async function within filter, so I've
left it for now
- this helps bring all the code together so we can extract it in the
future
- turning it into a class also lets us easily inject the i18n instance
and store it locally
refs https://github.com/TryGhost/Ghost/issues/12402
- Describes different types of jobs that could be executed depending on the nature of the jobs.
- Lays down ground rules on how to design scheduled jobs
no issue
- When providing a crontab schedule expression it should always contain 6 elements first one of them being a "seconds" schedule description . For example: '0/5 * * * * *' - meaning to run every 5 seconds
