fixes#8402
test plan:
* create a user via SIS with no e-mail
* add an e-mail address and remove it from the user's profile
* add the same e-mail address, and confirm it this time
* re-import the user via SIS, with the e-mail address this time,
but differing in case
* it should succeed, and the e-mail address should be update to
the new case
Change-Id: Id54f413bdf6b3c066530c53715141c7507d18f9b
Reviewed-on: https://gerrit.instructure.com/10552
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
fixes#7159
test plan:
* import two users with the same e-mail into the same account
* the user should not get a merge notification e-mail
Change-Id: Ic9f3a3948df1e2a877fcd8e79f3d05d86a2d1e5b
Reviewed-on: https://gerrit.instructure.com/8774
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* create a user via the UI
* add another pseudonym
* delete the extra pseudonym
* import a new user via SIS import with the login of the pseudonym
you deleted
* it should create a separate user for the SIS user, instead of
resurrected the deleted pseudonym onto the original user
Change-Id: Ia1ff1490bae82fc4daef3f91b05293d7c79cc50b
Reviewed-on: https://gerrit.instructure.com/7975
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan: run the migration
Change-Id: I75184edd64ddee384de485c443d4c7eee45cc26f
Reviewed-on: https://gerrit.instructure.com/7895
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
so that it's case insensitive
also fix some latent CommunicationChannel.find_or_initialize_by_path
discovered by specs for this
test plan:
* run the specs
* use forgot password with a username that differs in case
* self-register a new user multiple times (without confirming)
with e-mail addresses that differ in case
Change-Id: I476325f591c997fc8d50d5f38480177f732f07a7
Reviewed-on: https://gerrit.instructure.com/7724
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* import a user via SIS
* do another SIS import that lists the same user, and a new user
* the e-mail addresses for each user should be correct
Change-Id: I0a95804056e38bdfd36f24c0c78187d601940451
Reviewed-on: https://gerrit.instructure.com/7833
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* create a user via SIS import with an e-mail address
* add a different e-mail address to the user
* re-import the user via SIS, and set their e-mail address
to the second e-mail you added, but with a different case
* the user should have a single e-mail address, the one set
in the second SIS import
Change-Id: Iab6b16e0b37cfb8caac3faa453be570b99621a9e
Reviewed-on: https://gerrit.instructure.com/7784
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
* expose sortable name directly to the user
* don't downcase it
* use a LOWER(sortable_name) index for postgres
* set sortable name as "last_name, first_name" explicitly for SIS imports
* populate sortable name intelligently in the UI
Change-Id: I476641f4817e27a11b573d91f102c5a74d3eba26
Reviewed-on: https://gerrit.instructure.com/6512
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Ryan Florence <ryanf@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>
notable changes:
* nothing is processed as a sis-import blocking error now. bad imports now
result in warnings, while just skipping bad data
* we no longer check for duplicates before going to the database
Change-Id: Iedc96b29d92caccdc6a71ae1de8100a1c82dd137
Reviewed-on: https://gerrit.instructure.com/5724
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
It wasn't handling removing the association on the transition to deleted state.
Change-Id: Ia9f0714b8eba200531b5e2764c1c4f152f8ff8be
Reviewed-on: https://gerrit.instructure.com/5380
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Also clear old whitespace that was missed before this fix
closes#5448
Change-Id: I6096685223c43bfec9fd0c669c737af422687e10
Reviewed-on: https://gerrit.instructure.com/5354
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
optimize crosslisting itself:
* use ids where possible to avoid unnecessarily loading up objects
* Don't worry about keeping track of if we need to save; we're gonna
save anyway
* update account associations on any account change, not just root
account change (if you re-crosslist a section from one sub-account
to another sub-account, the users may no longer be associated with
the first sub-account).
optimize sis imports:
* really batch up update_account_associations
Change-Id: Ic0fbe1601afcbcd3e6540e69febc2e6a1a94157f
Reviewed-on: https://gerrit.instructure.com/5137
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
This was already a small issue if the job queue was on a different
database driver than the main database, and it'll become more important
as more AR connections are introduced.
Change-Id: I204becadd32bb935df096e8c937a04bb6962f0b2
Reviewed-on: https://gerrit.instructure.com/4601
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
For "small" imports (<5000 users), this improves wall-clock time
only a bit, but is much much nicer to the db. The larger the
import, though, the more the improvement here.
Be careful that we only use transactions on things that wouldn't
block other imports running in parallel, or even progress updates
running on the same thread.
Also be smarter about how often we update progress, since that
transaction can have a considerable impact on wall clock time.
refs #3752
Change-Id: I8a79bc530f5433858ccf7d62d33b98ba25e98ffa
Reviewed-on: https://gerrit.instructure.com/3613
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
* Only save the pseudonym once
* Avoid saving the user and pseudonym if nothing actually changed
* Related to that, since we skipped updating sis_batch_id
individually, we still need to do that, so do it en-masse instead.
updated_at will *not* get updated now.
These changes make re-importing the same data 3x faster than the
original import (it used to be less then 2x as fast as the original
import).
Change-Id: Ia6ea32cdeb2f4aebe041d8a51b9efe6c89bc819c
Reviewed-on: https://gerrit.instructure.com/3558
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
users need to be 'registered' not 'active'
closes#3744
Change-Id: Ia32aa3a32689c98fd17ea19594e3d314f9e3918f
Reviewed-on: https://gerrit.instructure.com/2205
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Cody Cutrer