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>
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>
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>
Jeremy Stanley