Skip to content
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

Add a grace window for expired regs to renew #290

Merged
merged 10 commits into from
Nov 5, 2018

Conversation

Cruikshanks
Copy link
Member

@Cruikshanks Cruikshanks commented Oct 27, 2018

https://eaflood.atlassian.net/browse/WC-512

Currently when the registration expires there is no mechanism to still start the renewal. Our NCCC team have made a strong case that this is problematic for a number of reasons, and as such they are finding they are having to implement a workaround which involves

  • creating a new registrations for users whose reg has expired (customer not happy they have lost their reg. number)
  • refunding the user for the difference between a new reg and a renewed one (NCCC and finance not happy because of the extra time and effort this takes)

The reasons given for still permitting a user to renew are

  • Current content around the expiry date in both the service and the EPR generally just says "Expiry date". So for example "Expiry date: October 15 2018". However NCCC report that its a common complaint to them that users read this as it expires at October 15 midnight, and as such is still valid to renew on the 15th.
  • Currently with no self serve mechanism to transfer or change the account email of a registration, users who have an expiry date on a weekend, may attempt to renew on the Friday, find they are locked out, and have to wait to the next business day to report the issue, by which time they have expired.

So this change is about still allowing registrations which have expired to renew, as long as that expiry falls within a predefined "grace window".

@Cruikshanks Cruikshanks added the enhancement New feature or request label Oct 27, 2018
@Cruikshanks Cruikshanks self-assigned this Oct 27, 2018
Pinpointed where in the exisiting specs to add our unit tests for the 'grace window'.
We need to add config so that the renewals engine understands what the grace window is, and with this in place we can also bring it into our unit tests.

The inside grace window still fails, but at least we have a failing test to work with.
Update the `CanChangeRegistrationStatus` concern so that it knows about the grace window and uses this knowledge in its determination as to whether something can be renewed.
The grace window changes essentilly means simply marking a registration as `EXPIRED` no longer means it is expired.

So a number of tests that check you are redirected to a unrenewable page at various stages of the journey started failing because in the setup all they did was call `registration.metaData.expire!`.

This change also ensures that the expiry date is set to something that is outside the grace window, so our new code that determines whether something can be renewed returns false.
@Cruikshanks
Copy link
Member Author

Cruikshanks commented Nov 1, 2018

@irisfaraway Fixed my failing tests, and they all needed fixing in the same way. I'm happy I've kept in keeping with what the test was trying to do, but got a niggle in the back of my mind that the way I've solved the problem might not be the best. Let me know if you think there is a better way.

Copy link
Member

@irisfaraway irisfaraway left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly similar stuff to the frontend PR. I'm not too fussed about the tests but may have an idea to cut down on the lines.

Perfectly valid feedback that we should be splitting the existing logic into 2 lines; work out what the end date of the grace window is, then compare this against the current date.
In my rush to ship I added the check for whether a renewal is in the grace window to the `should_not_be_expired?` method. However as was rightly pointed our in the PR

> This method was initially intended to check whether the registration's status should be 'EXPIRED' and would be changed as soon as the scheduled job hit it, thus the concept of "should be expired".

If a registration was in the grace window, it should still be expired it just happens it can also be renewed.

Thankfully a simply fix, and much betterv place for the grace window check was to move it to the renewal_allowed? method.
Spotted that `CanChangeRegistrationStatus.close_to_expiry_date?` was not using `expiry_time_adjusted_for_daylight_savings.to_date` to determine the expiry date before then using it in the logic.

It should be, so corrected under the 'boy scout rule'.
Found a test that was broken first by the order of checks in `renewal_allowed?`, but also when I started debugging found we should also be checking in `in_expiry_grace_window?` that the current day was not just before the last day of the grace window, but that it also came after the expiry date of the registration.

Also had a funny with the grace window being 0, so updated tests to account for this.
Took on the suggestion in the PR feedback to simplify how we denote expired registrations by using a one liner that sets the `expires_on` date outside of the grace window.
@Cruikshanks Cruikshanks merged commit e5d5f42 into master Nov 5, 2018
@Cruikshanks Cruikshanks deleted the add-grace-window-expired-regs branch November 5, 2018 12:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants