-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow for multiple grace window rules in engine #913
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
https://eaflood.atlassian.net/browse/RUBY-1210 Currently we have the COVID extension in place in the engine, with an additional ruleset overriding it in the back office if a feature flag is on. We want to be able to continue to apply the COVID extension to registrations which previously had it, while applying the regular rules to any registrations expiring after the extension, and also still having the option for the feature-flagged ruleset to take effect as well. This also includes substantial refactoring of the ExpiryCheckService as it was doing way too many things at once and splitting it up will make this much easier.
Also stop it from returning 1970 for lower tier registrations. Unclear why this was the case but I'm sure it'll break something else and then we'll find out.
Working out the last day should be separate from checking if the registration has passed it or not. This will also mean we don't need to override anything in the back office, just set permissions.
This entire service is in serious need of breaking up into smaller chunks but this will have to be a start. Had to make some changes to the specs as well, mainly to deal with there being two different grace windows depending on what date the tests are run. A new helper class should manage this for us.
Was hoping we could do something with user permissions to only allow certain users to do the extended renewal in the back office, but for now I think it is complicating already complex changes. So switching to just use check if it is the back office or not.
This should deal with registrations that are lower tier, or fit the rules for upper tier regs that did and did not have the COVID extension applied.
This will mean we can entirely get rid of the overriding back office method.
irisfaraway
force-pushed
the
feature/grace-window-rules
branch
from
September 28, 2020 15:54
f10df75
to
092de33
Compare
This was referenced Sep 28, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
https://eaflood.atlassian.net/browse/RUBY-1210
Currently we have the COVID extension in place in the engine, with an additional ruleset overriding it in the back office if a feature flag is on.
We want to be able to continue to apply the COVID extension to registrations which previously had it, while applying the regular rules to any registrations expiring after the extension, and also still having the option for the feature-flagged ruleset to take effect as well.
This also includes substantial refactoring of the ExpiryCheckService as it was doing way too many things at once and splitting it up will make this much easier.