closes EVAL-3285
[fsc-timeout=30]
We will need to follow this up next release with a commit
to remove the alias `DueDateCacher = SubmissionLifecycleManager`.
flag=none
Test plan
- Tests pass
Change-Id: Ib3566e9d581f5826ab07ee2265277bb75ba02ee0
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/320685
Migration-Review: Isaac Moore <isaac.moore@instructure.com>
Reviewed-by: Spencer Olson <solson@instructure.com>
Reviewed-by: Christopher Soto <christopher.soto@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Cameron Ray <cameron.ray@instructure.com>
Product-Review: Cameron Ray <cameron.ray@instructure.com>
[skip-stages=Flakey]
auto-corrected for the most part, but I went through specs and used
the have_key matcher when possible
Change-Id: I4a2df1cdd536a94f3b493668386883d1148660c9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278050
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
This occurs when a student was previously enrolled in a course, had
grades, removed from the course, and then enrolled into a section of
the course that they were not previously enrolled in. The grade
calculator was not running as they re-enrolled, despite having prior
graded submissions.
fixes GRADE-2193
Test Plan
- Enroll a student in a course.
- Create an assignment.
- Grade the student.
- Delete the enrollment, and any other enrollments the student may
have in the course.
- Create a new section.
- Enroll the student in the new section.
- Do not accept the invitation yet.
- Hit the enrollments endpoint and verify that it returns non-null
scores for the student:
GET `api/v1/users/6/enrollments`
Change-Id: Ib12ee4a99eff4db7951b216abd1bed2bb4690990
Reviewed-on: https://gerrit.instructure.com/200124
Tested-by: Jenkins
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Reviewed-by: Derek Bender <djbender@instructure.com>
QA-Review: Adrian Packel <apackel@instructure.com>
Product-Review: KC Naegle <knaegle@instructure.com>
closes GRADE-1487
Test plan:
- Specs pass
- Smoke test the following for an anonymous (or otherwise auditable)
assignment:
- Changing the due date for the whole assignment, a particular
section, or a particular student
- Adding or removing a student
- Updating student groups
- Updating grading periods
- Smoke test the above for a non-auditable assignment and make sure the
functionality works as expected
Change-Id: I31858a38059bc3ff73d91dd138ffa20cd8a76fac
Reviewed-on: https://gerrit.instructure.com/164776
Reviewed-by: Derek Bender <djbender@instructure.com>
Reviewed-by: Keith T. Garner <kgarner@instructure.com>
Tested-by: Jenkins
QA-Review: James Butters <jbutters@instructure.com>
Product-Review: Keith T. Garner <kgarner@instructure.com>
This patchset changes calls of DueDateCacher.recompute_course to
DueDateCacher.recompute_users_for_course in places where we only have
specific enrollments or users we can work on and avoid doing the work
of the entire class.
fixes GRADE-1129
test plan:
- specs pass
Change-Id: Ia6814e4584993bd9d0f2ba330eb33c3a635ca0e1
Reviewed-on: https://gerrit.instructure.com/148854
Tested-by: Jenkins
Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com>
Reviewed-by: Spencer Olson <solson@instructure.com>
QA-Review: Anju Reddy <areddy@instructure.com>
Product-Review: Keith T. Garner <kgarner@instructure.com>
for my sanity because it's too confusing to actually refactor
closes #CORE-1140
Change-Id: I445e0edeb3fde76ffd02a467180ee7a83d916067
Reviewed-on: https://gerrit.instructure.com/143538
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
closes GRADE-701
test plan:
* Create and publish a course and enroll five students in it
* Create and publish an assignment and add an override with a due date
that includes all five students
* From the Rails console, verify all students have the same due date
# a is the Assignment you created above
a.reload.submissions.map(&:cached_due_date)
* Go to the assignment details page
* Verify it shows one override with its corresponding due date and the
description "5 students"
* Conclude the enrollment of one of the students and go back to the
assignment details page
* Verify it now shows one override with its corresponding due date and
the description "4 students"
* Change the due date of the override to a different date
* From the Rails console, verify all students have the same due date
except the concluded student, who should still have their old due
date
# a is the Assignment you created above
a.reload.submissions.map(&:cached_due_date)
* Deactivate another student and go back to the assignment details page
* Verify it now shows one override with its corresponding due date and
the description "3 students"
* Change the due date of the override to a different date
* From the Rails console, verify all students have the same due date
except the concluded student, who should still have their old due
date. The inactive student should have their due date updated to the
one you just entered
# a is the Assignment you created above
a.reload.submissions.map(&:cached_due_date)
* Restore the enrollment of both students and go back to the assignment
details page
* Verify it now shows one override with its corresponding due date and
the description "5 students"
* Change the due date of the override to a different date
* From the Rails console, verify all students have the same due date
including the student who was previously concluded but was just
unconcluded
# a is the Assignment you created above
a.reload.submissions.map(&:cached_due_date)
Change-Id: Ifd64afcfffb5924f29710545d403e53470241a41
Reviewed-on: https://gerrit.instructure.com/134158
Reviewed-by: Derek Bender <djbender@instructure.com>
Reviewed-by: Spencer Olson <solson@instructure.com>
Tested-by: Jenkins
QA-Review: Indira Pai <ipai@instructure.com>
Product-Review: Keith T. Garner <kgarner@instructure.com>
make user_lists v2 and invite_users return a `user_token`
in addition to id, and make enroll_users accept an array
of these instead of ids
test plan:
- regression test the "+ People" functionality on the
course People page
- using each way to find people
- when finding existing users and creating new users
- when finding a user in another shard
fixes ADMIN-265
Change-Id: I792a50d2d9504d13471794889708a69d11144fdd
Reviewed-on: https://gerrit.instructure.com/131933
Tested-by: Jenkins
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: KC Naegle <knaegle@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
test plan:
* should be able to post to the /courses/:id/enroll_users
endpoint with a "user_ids" array instead of a "user_list"
to bulk enroll users in a course
closes #CNVS-32188
Change-Id: I60dea5ca748ac2732b9187c0f3f4b26811d35dd6
Reviewed-on: https://gerrit.instructure.com/91529
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: Chris Ward <cward@instructure.com>
Tested-by: Jenkins
take a few steps to avoid murdering the database:
1. split enrollments into multiple smaller transactions
2. touch only users whose enrollments have changed
3. batch-touch users after the transactions complete
test plan:
- regression test enrolling lists of users on the
course People page
fixes CNVS-27724
Change-Id: Ib6a8997648398ae8e3e273a0a386decae47cf4c7
Reviewed-on: https://gerrit.instructure.com/73642
Reviewed-by: James Williams <jamesw@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
(note that the Enrollments API already works this way,
and the Edit Sections dialog can be used to accomplish this
also)
test plan:
0. have a course with multiple sections
1. have a user with a login
2. use the Add People dialog to enroll the user in the course
3. use the Add People dialog again, to enroll the same user
with the same enrollment type as before, but choose a
different section from the dropdown
4. the user should be enrolled in both sections
fixes CNVS-17594
Change-Id: Ia39537591c779af9ba3fc3163a32d6487c2c4e88
Reviewed-on: https://gerrit.instructure.com/46165
Reviewed-by: Jon Willesen <jonw@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
Product-Review: Hilary Scharton <hilary@instructure.com>
refactor everything that used to use strings for roles
to use actual role_ids
the apis should be backwards compatible so we don't need
to update (most of) the UI's right away in this commit
test plan:
* regression tests for permissions, role overrides,
alerts (for account roles), enrolling users,
adding account admins, etc.
refs #CNVS-15481
Change-Id: Id57fd3104c5c518b6fbf180609950dcddcdd474d
Reviewed-on: https://gerrit.instructure.com/41208
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-9522
in rails3 ActiveRecord::Base.skip_callback is a real thing that doesn't
do what this does. because of load order, ours happens, but it would be
nice to leave the other available.
to simplify the switch, both suspend_callback and suspend_callbacks are
kept as renames, but suspend_callback should not be used, preferring
suspend_callbacks. suspend_callback will go away in the near future.
skip_callback is temporarily added back in as an alias to
suspend_callback to allow time for fixing a plugin that uses
skip_callback. it will be removed as soon as that plugin is updated.
Change-Id: Iaefd16dde3b6ce575780cb8f721dc826258eef4e
Reviewed-on: https://gerrit.instructure.com/29808
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
deleting a user could cause thousands of update-cached-due-dates
jobs to be enqueued (one per assignment per enrollment; in the
referenced ticket, the test student had 13 enrollments and there
were 88 assignments, yielding 1,144 jobs, causing the request
to time out).
fix this by
(1) using a batch job to update all assignments in the course,
instead of a job per assignment
(2) when deleting a user with multiple enrollments in a course,
only run the update cached due date job once per course
test plan:
0. run in "production" configuration (i.e., in QA portal)
1. have a course with 10 sections and 100 assignments.
I suggest creating these in the console, e.g.
course = course.create! name: "CNVS-8068"
10.times { |x| course.course_sections.create! name: "section #{x}" }
100.times { |x| course.assignments.create! name: "assignment #{x}" }
2. enter student view mode in this course
3. reset the student view student
4. verify 1000 jobs were not created (and the request doesn't time out)
fixes CNVS-8068
Change-Id: If00dd3197b70df42b0f9ec18303b02594861f69f
Reviewed-on: https://gerrit.instructure.com/25160
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
refs CNVS-8071
test plan:
* create a course and a section with an SIS ID
* create a an assignment, and override it's date for that section
* enroll two users via UI into the course; one with no section
(i.e. the default section), and one into the section with the override
* confirm that the users show appropriate due dates for the assignment
Change-Id: I5e06f812dbe8afe08eebb8c8809699c8ef685746
Reviewed-on: https://gerrit.instructure.com/24257
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
You can add enrollments with the custom roles and see who
has the roles.
Test Plan:
* Create custom roles for each enrollment type
* Test all the settings page's functionality like adding/deleting users with custom roles
* Make custom observers observe students in various combinations of custom roliness
- verify that the new observer role has the custom role
* Make sure the section limited check box shows up for custom tas/teachers by selecting those options in the new user select box
closes #cnvs-1166
Change-Id: I5f133bf1b5b1438d7f8e34297b450ff561d401d0
Reviewed-on: https://gerrit.instructure.com/16272
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
it was misleading to begin with, and downright buggy when combined
with open registration
test plan:
* go to add a user to a course as an admin. no more checkbox
Change-Id: Ibb40bae6f5b0a43fe66b2d809d56a256e06e57ba
Reviewed-on: https://gerrit.instructure.com/8537
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
enrollments previously had attribute
"limit_priveleges_to_course_section," but should
be spelled "privileges." replaced spelling in a
migration and across app.
affects: enrollments model
test plan:
* run specs
Change-Id: I15dcf9a023ead9bb1aed42abc2d1a7c233610840
Reviewed-on: https://gerrit.instructure.com/7431
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#5573, #5572, #5753
* communication channels are now only unique within a single user
* UserList changes
* Always resolve pseudonym#unique_ids
* Support looking up by SMS CCs
* Option to either require e-mails match an existing CC,
or e-mails that don't match a Pseudonym will always be
returned unattached (relying on better merging behavior
to not have a gazillion accounts created)
* Method to return users, creating new ones (*without* a
Pseudonym) if necessary. (can't create with a pseudonym,
since Pseudonym#unique_id is still unique, I can't have
multiple outstanding users with the same unique_id)
* EnrollmentsFromUserList is mostly gutted, now using UserList's
functionality directy.
* Use UserList for adding account admins, removing the now
unused Account#add_admin => User#find_by_email/User#assert_by_email
codepath
* Update UsersController#create to not worry about duplicate
communication channels
* Remove AccountsController#add_user, and just use
UsersController#create
* Change SIS::UserImporter to send out a merge opportunity
e-mail if a conflicting CC is found (but still create the CC)
* In /profile, don't worry about conflicting CCs (the CC confirmation
process will now allow merging)
* Remove CommunicationChannelsController#try_merge and #merge
* For the non-simple case of CoursesController#enrollment_invitation
redirect to /register (CommunicationsChannelController#confirm)
* Remove CoursesController#transfer_enrollment
* Move PseudonymsController#registration_confirmation to
CommunicationChannelsController#confirm (have to be able to
register an account without a Pseudonym yet)
* Fold the old direct confirm functionality in, if there are
no available merge opportunities
* Allow merging the new account with the currently logged in user
* Allow changing the Pseudonym#unique_id when registering a new
account (since there might be conflicts)
* Display a list of merge opportunities based on conflicting
communication channels
* Provide link(s) to log in as the other user,
redirecting back to the registration page after login is
complete (to complete the merge as the current user)
* Remove several assert_* methods that are no longer needed
* Update PseudonymSessionsController a bit to deal with the new
way of dealing with conflicting CCs (especially CCs from LDAP),
and to redirect back to the registration/confirmation page when
attempting to do a merge
* Expose the open_registration setting; use it to control if
inviting users to a course is able to create new users
Change-Id: If2f38818a71af656854d3bf8431ddbf5dcb84691
Reviewed-on: https://gerrit.instructure.com/6149
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
* Manually cache account chains (query cache gets dumped after every
update or delete)
* Use batch queries and preloads to make the number of queries
constant wrt how many users are getting updated
* Simplify calculation - find the root account ids, and merge the
account chains together
* Fix depth to be defined as the minimum depth to reach that account
(rather than whichever path happened to be processed last)
* Add incremental mode to only add accounts, rather than re-calculate
all associations (only for User)
* Don't auto-create the default section during
update_account_associations; it costs a query and possibly an
insert, causes angst with schools that don't want it, etc.
Instead, always create associations against a 'nil' section so
that a course has the proper associations.
Change-Id: I7d476d45f41d9c3e382fac9b5c0c0aaa5369b956
Reviewed-on: https://gerrit.instructure.com/5135
Tested-by: Hudson <hudson@instructure.com>
Tested-by: Selenium <selenium@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
also adds enrollments in batches, instead of one at a time via ajax.
closes#4835
Change-Id: Ic2aac24db2c4d5fb4482901daf8627419c548e37
Reviewed-on: https://gerrit.instructure.com/4584
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Cameron Ray