10f47ed85e
Assignments and classic quizzes will date shifting now become
an initial operation instead a late update to avoid
unnecessary lifecycle hook triggers.
refs CLAB-102
flag=pre_date_shift_for_assignment_importing
test plan:
# Setup
Create a course (SC) with:
- Assignment
- Quiz
- Graded Discussion
On all 3 set due date to a past date and other dates to something.
# With flag off (current behavior)
Create a new course
go to courses/{id}/content_migrations
use Copy a Canvas course
Source course should be SC
Select All content
Select Adjust events and due dates
Click remove dates
Import
Go to imported resources and verify that
due dates and other dates are gone.
Create a new course, do same import but
adjust dates instead of removing them.
Verify dates were adjusted as expected.
# With flag on
Enable pre_date_shift_for_assignment_importing
Create a new course
Test both scenarios of Adjust events and due dates
Expect same results
# Race condition
Ensure flag is on
Testing the race condition with SubmissionLifecycleManager
Create a new course
Create a student user, add to course, accept invite
in AssignmentImporter#try_to_save_with_date_shift
add "binding.irb" on line 607
open terminal
cd canvas-lms
docker compose stop jobs
docker compose run jobs (do the same in another terminal)
bundle exec script/delayed_job run (in both shells)
Import SC into new course
one of the job processes will pick up the job
and give you an irb
"item.save_without_broadcasting"
"SubmissionLifecycleManager.recompute(item)"
"item.submissions" should be empty or should have no graded subs
Change-Id: Ide39a552b625c099c0c87fc6166cd9bd37a0ab15
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/357178
Reviewed-by: Spencer Olson <solson@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Rajmund Csehil <rajmund.csehil@instructure.com>
QA-Review: Rajmund Csehil <rajmund.csehil@instructure.com>
Product-Review: Rajmund Csehil <rajmund.csehil@instructure.com>
QA-Review: Ferenc Marcsó <ferenc.marcso@instructure.com>
|
||
|---|---|---|
| .. | ||
| activesupport-suspend_callbacks | ||
| acts_as_list | ||
| adheres_to_policy | ||
| attachment_fu | ||
| autoextend | ||
| bookmarked_collection | ||
| broadcast_policy | ||
| canvas_breach_mitigation | ||
| canvas_cache | ||
| canvas_cassandra | ||
| canvas_color | ||
| canvas_crummy | ||
| canvas_dynamodb | ||
| canvas_errors | ||
| canvas_ext | ||
| canvas_http | ||
| canvas_kaltura | ||
| canvas_mimetype_fu | ||
| canvas_panda_pub | ||
| canvas_partman | ||
| canvas_quiz_statistics | ||
| canvas_sanitize | ||
| canvas_security | ||
| canvas_slug | ||
| canvas_sort | ||
| canvas_stringex | ||
| canvas_text_helper | ||
| canvas_time | ||
| canvas_unzip | ||
| config_file | ||
| csv_diff | ||
| diigo | ||
| dr_diff | ||
| dynamic_settings | ||
| event_stream | ||
| google_drive | ||
| html_text_helper | ||
| i18n_extraction | ||
| i18n_tasks | ||
| incoming_mail_processor | ||
| json_token | ||
| legacy_multipart | ||
| live_events | ||
| lti-advantage | ||
| lti_outbound | ||
| paginated_collection | ||
| plugins | ||
| request_context | ||
| rubocop-canvas | ||
| stringify_ids | ||
| tatl_tael | ||
| turnitin_api | ||
| utf8_cleaner | ||
| workflow | ||
| README.md | ||
| gemfile_prefix.rb | ||
| test_all_gems.sh | ||
README.md
Gems
This folder is a place to extract modular functionality from canvas. Canvas's Gemfile arrangement is enabled to read gems from this path locally without installing from a remote source. This is valuable for a few reasons:
- it prevents circular dependencies (bundler won't allow it)
- modularized code cannot bind to specific domain concepts on canvas models
- gems can have their specs run independently, without needing to load all of canvas, saving iteration time
- it allows for eventual build optimization via only running specs for the transitive closure of parents depending on a gem where a change is.
There are some tradeoffs:
- spreads canvas over more subdirectories, giving some mental overhad to traversing the entire codebase.
- modular tests necessarily don't test integration with canvas concepts, so solid integration tests in the app are still a requirement.
- total SERIALIZED build time goes up because each gem loads it's specs in a new process rather than all running within an already booted canvas process.
[TODO] eventually write more on whether we feel like those tradeoffs are good ones, and what the best practices are to leverage this pattern for max-gain/min-pain.
Testing
To test all the gems:
cd gems
./test_all_gems.sh
To test an individual gem
Run ./test.sh inside the gem's folder. This is basically the same as:
cd gems/google_drive
bundle
rspec