-
Notifications
You must be signed in to change notification settings - Fork 479
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
Prevent moving scripts between unit groups when they have resources or vocabulary #38702
Prevent moving scripts between unit groups when they have resources or vocabulary #38702
Conversation
…dding a script with resources or vocabulary to a unit group
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.
Nice progress Bethany! The new tests look good too.
dashboard/db/schema.rb
Outdated
@@ -466,7 +466,7 @@ | |||
t.index ["name", "version"], name: "index_foorm_forms_on_name_and_version", unique: true | |||
end | |||
|
|||
create_table "foorm_libraries", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci", force: :cascade do |t| | |||
create_table "foorm_libraries", options: "ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci", force: :cascade do |t| |
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 line looks like it should be reverted
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.
Oops -- this file shouldn't be committed here at all 🤦♀️
script = Script.find_by_name!(script_name) | ||
if scripts_to_delete.any?(&:prevent_course_version_change?) | ||
raise 'Cannot remove scripts that have resources or vocabulary' | ||
end |
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 am trying to wrap my head around what we will do in the case where a curriculum writer decides that they do not want a unit in their unit group any more. perhaps the curriculum writer will have to keep the script in the unit group until they are ready to destroy it entirely?
I don't necessarily see a better way, and I'd rather have this protection than not. So I am ok with waiting for someone to run into this before dealing with 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.
If it doesn't have resources or vocabulary, it should be possible to remove it still. If it does, the options are going to be to go through each lesson and remove these objects or wait until they want to destroy it entirely I guess.
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 will admit the error handling is not pretty on this but I'd be surprised if this is an error path hit commonly.
Almost feels like resources and vocabularies should be primarily associated with a script (or with a course version? Whichever model is the closest to the source of truth for versioning), and then lessons should do something like reference some subset of that content for the script that they're in, rather than themselves being directly associated with resources and vocab. |
dashboard/app/models/unit_group.rb
Outdated
|
||
new_scripts.each_with_index do |script_name, index| | ||
script = Script.find_by_name!(script_name) | ||
if scripts_to_delete.any?(&:prevent_course_version_change?) |
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.
is there a reason we want this logic to live here, rather than in, say, a before_destroy
hook on Script?
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.
The variables could be better named but this isn't actually destroying a script, just removing it from the unit group.
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.
ahhhhh, right. Yeah, something like scripts_to_remove
would be clearer
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.
Agreed -- I'll make that change
Vocabularies and resources are directly associated with a course version, which is how we do that versioning you're referencing. I'm not sure I understand what you're suggesting about referencing a subset? I'm very open to adjusting how we maintain these associations if we can do it without breaking things so ideas are very welcome :) |
Oh, nice! We're halfway to my suggestion already, then. So right now, resources are unique per |
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.
to clarify: my suggestions for an alternative approach are suggestions for future work, not something I think we need to do in this PR.
This change LGTM for what it is! Love the tests, too; very clear.
Thank you for suggesting this, Elijah! I think there have been a bunch of times recently where the topic of "decoupling vs deduplication" have come up, and so far we (our team, the org, etc) have tended to side with deduplication. is this a case where the approach you're suggesting has a benefit that you'd describe as "decoupling", or is there another motivation? |
I don't know that I'd describe it as either decoupling or deduplication. Rather, this is about recognizing that the underlying implementation does not align with our intended usage scenarios. Or at least it doesn't align as well as it could. Right now we're addressing this by adding some situational logic to make sure that we avoid one scenario in which the misalignment could cause an issue. I'm suggesting that there is an underlying implementation which could be better aligned, and would render this special logic unnecessary. |
A step in PLAT-505. This PR prevent adding or removing a script from a unit group if any lessons in that script have resources or vocabulary. This PR does not handle standalone scripts as I was having trouble getting that to work.
I'm definitely open to ideas on how to do this better. I originally wanted to add a model validation but I struggled to figure out where.
So I've gone for the strategy of "closing the gaps". This unfortunately means that in places we'll have to bake the logic of how these relationships work into the code more than I'd like.
Background
Resources and vocabulary belong to a course version and it is expected that they belong to the same course version as any lesson they're in. This becomes an issue if a script's course version changes as the resources and vocabulary in lessons in that script will still belong to the previous course version.
Links
Testing story
Reviewer Checklist: