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
Update circuit playground discount code applications for 2020 #32179
Update circuit playground discount code applications for 2020 #32179
Conversation
dashboard/app/models/circuit_playground_discount_application.rb
Outdated
Show resolved
Hide resolved
@islemaster before I make some changes to allow this to work correctly for AK/HI teachers, could use your two cents on this point: 4. Allows for teachers to get either a full discount code with or without shipping (with shipping codes to be used for Alaska and Hawaii partners). The approach I'm proposing here is that the full_discount flag on CircuitPlaygroundDiscountApplication would be 0 if a teacher is getting a discount code without shipping, and 1 if they are getting one with shipping (this I think is inconsistent with last year, if "full discount" discount codes last year were without shipping). Do you care if there's inconsistency there in whether this year full discount (without shipping) is represented as 0 for I could change the column type and make it something like this, but it would be nice to keep it as a boolean, methinks. |
I'm not worried about year-over-year inconsistency at all, as long as we think it's documented and understandable for someone to revisit next year. IMO |
@islemaster I dug in a bit this morning, and I'm worried that the 0/1 The options I see are:
I'm leaning towards option 2. Thoughts? |
I'd still lean toward option 1. I don't think we read Happy to sit down and look at this together tomorrow, if you'd like. |
@@ -72,7 +73,7 @@ export default storybook => { | |||
) | |||
}, | |||
{ |
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.
Let's add stories to this file for the scenario where the academic year PD requirement has not been passed.
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.
Done!
@@ -54,11 +53,11 @@ def self.find_by_studio_person_id(studio_person_id) | |||
end | |||
|
|||
# @return {boolean} true if user is an eligible facilitator or attended relevant workshop |
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.
Please update this doc comment to explain the new workshop_subjects parameter.
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.
Updated -- I'm not familiar with YARD yet (which is looks like is what we use for our docs?), so hopefully this is syntactically ok.
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.
👍 Seems fine. We're not actually generating these docs, so syntax errors in YARD are not a big deal right now.
@@ -54,11 +53,11 @@ def self.find_by_studio_person_id(studio_person_id) | |||
end | |||
|
|||
# @return {boolean} true if user is an eligible facilitator or attended relevant workshop | |||
def self.user_pd_eligible?(user) | |||
user_pd_eligible_as_teacher?(user) || user_pd_eligible_as_facilitator?(user) | |||
def self.user_pd_eligible?(user, workshop_subjects=nil) |
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.
Why did you choose a nil default for this parameter? That passes through to the query below and would match workshops with a NULL
subject, which doesn't make sense to me as a default. If it's possible to simply remove the default and require this parameter, I'd prefer that.
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.
I made it nil by default so you could still pass in a facilitator's user ID and get a returned value of true, something like this.
I didn't consider the impact of matching a workshop with a null
subject though.
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.
Did a quick scan and it looks like we don't ever call this method without a second argument in production code, only in test code. Let's remove the default value and any tests covering that behavior.
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.
Sounds good -- for the record, I think the link I put here wasn't to the right test, more like the one titled "studio_person_pd_eligible? returns true if studio_person_id associated User is approved facilitator" is relevant.
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.
Updated -- I kept most tests for facilitators in place, just added the 5-day workshop as the workshop_subjects
argument. I think this tests what we'd see in the wild (facilitators going through the normal flow with no enrollments associated with their accounts, but with their user ID in the list of facilitators).
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.
👍 Great!
@@ -111,13 +112,25 @@ def self.application_status(user) | |||
has_confirmed_school: application.try(:has_confirmed_school?) || false, | |||
school_id: school_id, | |||
school_name: school_id ? School.find(school_id).name : nil, | |||
school_high_needs_eligible: School.find(school_id).try(:maker_high_needs?), |
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.
I liked your proposal to move the maker_high_needs?
implementation out of the School
model and into this one.
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.
Alternatively, we could create a policy object, a clean-architecture Ruby pattern @Hamms introduced into our project this year.
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.
I left this as-is for now -- could fix after break if we want.
Pd::Workshop::SUBJECT_CSD_WORKSHOP_6, | ||
Pd::Workshop::SUBJECT_CSD_VIRTUAL_8 | ||
] | ||
), |
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.
I wonder if we can deduplicate these 12 lines with the matching ones in self.application_status
?
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.
I put together a functional approach to to this (create a method that takes a user and creates a two element hash with keys is_pd_eligible
and is_quarterly_workshop_pd_eligible
, then merge that hash with the one created here). It seemed kind of funky / confusing though, is there a cleaner way to do that?
I think this is really close! Great work on this Ben. Once you've got the new full-discount logic done, I've got a few additional notes (above) to address. As follow-up work, after we merge this PR, we should ask whether the "everyone" discount code that is hard-coded into the system is still active this year, and whether we need that list of eligible facilitators at all (or if we can just remove that code). After all that, it might be interesting/useful to review the similar update to discount codes last year (#26382) and some fixes that happened not long after (#26823). |
Co-Authored-By: Brad Buchanan <brad@code.org>
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.
This looks great Ben! Next steps:
- Let's go ahead and change the base branch for this PR to
staging
now that it's open again. - Let's make sure we get a passing Drone run after the base branch change.
- I think we can merge this in before break, and do the new changes Amy brought to our attention in a follow-up PR before we re-enable this feature in January.
Thanks for all the attention to detail on this!
Sounds good, going to shoot to clean this up by EOD tomorrow. |
Description
full_discount
flag onCircuitPlaygroundDiscountApplication
would be 0 if a teacher is getting a discount code without shipping, and 1 if they are getting one with shipping (this may be inconsistent with last year, if "full discount" discount codes last year were without shipping).Known issues:
Need to add tests to account for new features (namely, check on attendance at Q4 workshop).
Links
Testing story
Reviewer Checklist: