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

Schedule the registration exemptions expiry job to run daily #256

Merged
merged 9 commits into from
Jul 9, 2019

Conversation

cintamani
Copy link
Contributor

@cintamani cintamani commented Jul 2, 2019

From https://eaflood.atlassian.net/browse/RUBY-413

Add configuration and scheduling of the registration exemptions expiry job

From https://eaflood.atlassian.net/browse/RUBY-413

This adds a rake task and a service object to deal with setting the status of a registration exemption to expired when it is in an active status and the expire date is in the past.
After talking about expiring on the day of expire or the day before, we have decided that the registration is considered expired after the date have passed, hence this include a fix on our logic for "not_expired" registrations too.
One more thing part of this PR is the definition of the RegistrationExemption table name which allow us to use the AASM default defined scopes.
From https://eaflood.atlassian.net/browse/RUBY-413

Add configuration and scheduling of the registration exemptions expiry job
@cintamani cintamani added the enhancement New feature or request label Jul 2, 2019
@cintamani cintamani self-assigned this Jul 2, 2019
@cintamani cintamani changed the title Schedule the registration exemptions expiry job to run daily [BLOCKED] Schedule the registration exemptions expiry job to run daily Jul 2, 2019
@cintamani cintamani changed the base branch from 413-expire-registration to master July 5, 2019 13:33
@cintamani cintamani changed the title [BLOCKED] Schedule the registration exemptions expiry job to run daily Schedule the registration exemptions expiry job to run daily Jul 5, 2019
irisfaraway
irisfaraway previously approved these changes Jul 5, 2019
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.

Just wondering – do we need a feature flag for this? Maybe unnecessary if we are planning to release it in the next round anyway (which would make sense).

Copy link
Member

@Cruikshanks Cruikshanks left a comment

Choose a reason for hiding this comment

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

This also means I'll need to go in and update .env.example and our tests to ensure they follow the same principle for the other jobs 😩 . But as there is no reason to be different in this case we might as well set the time to be what it will actually be unless there is a reason to be different.

.env.example Outdated Show resolved Hide resolved
.travis.yml Outdated Show resolved Hide resolved
config/schedule.rb Outdated Show resolved Hide resolved
@Cruikshanks
Copy link
Member

@irisfaraway One for our dev meetings I think about how we define what needs a feature flag. But I'd like to keep them to a minimum. So I'm currently going with

  • we've implemented the code but the 'switch on' needs to happen much later and we have other things we want to release
  • the functionality is part of a wider feature, and we don't want to enable it till everything related to the feature is done

In the case of this we want it running asap, and everything is good to go, so I don't think it needs a feature flag.

Co-Authored-By: Alan Cruikshanks <alan.cruikshanks@gmail.com>
@cintamani cintamani merged commit 8297990 into master Jul 9, 2019
@cintamani cintamani deleted the 413-scheduler branch July 9, 2019 09:32
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
3 participants