-
Notifications
You must be signed in to change notification settings - Fork 8
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
CST-2575: closing 2021 allow cohort changes for participants from payments-frozen cohorts #4831
CST-2575: closing 2021 allow cohort changes for participants from payments-frozen cohorts #4831
Conversation
Review app deployed to https://cpd-ecf-review-4831-web.test.teacherservices.cloud |
0dfae92
to
4f95dea
Compare
73dfb43
to
b48d134
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of small suggestions, nothing blocking though.
b71f26a
to
37c9d4d
Compare
4d687dd
to
e7f3f15
Compare
e7f3f15
to
ba983cb
Compare
end | ||
|
||
def active?(participant_profile) | ||
participant_profile&.active_record? && participant_profile&.training_status_active? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im curious as to why this changed, and we no longer want training status active? I've checked our service and we prevent changing things if a participant is withdrawn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the question we made to Nathan about setting training_status: :active when executing the cohort change via this tool we finally concluded to leave training_status as it was originally.
So why required the participants to be training_status: :active?
Also it feels to me that the original training status refers to that training period. Why would that block starting a new training period somewhere else?
In any case, happy to reinstate it if needed
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
having a think maybe we can keep it as it was currently? as I think resetting the training status is quite different than the validation itself. Just erroring on the side of caution as it's already there, if we later find it an issue maybe we can remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @ltello very minor comments/questions but generally looks great , and after @ethax-ross pr is merged we can align the methods :)
ba983cb
to
bdc3c58
Compare
f6f333b
to
a6747a6
Compare
a6747a6
to
d7fa262
Compare
d7fa262
to
d6fdb6c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks @ltello 🙌
…ter their cohort is frozen for payments
Co-authored-by: Steve Laing <[email protected]>
Co-authored-by: Steve Laing <[email protected]>
…payments-frozen cohorts
… their original cohort
7be3153
to
00efb07
Compare
Context
Accomodate Induction::AmendParticipantCohort service object to accept participants coming from payments_frozen cohorts.
This piece of code will eventually be called by all the features/journeys/events we are updating as part of the Closing 21 cohort implementation.
Ticket
Changes proposed in this pull request
Guidance to review