two breaking changes:
* validations are gone, just use vanilla rails validations
* authenticates_many is gone. use a scoping call instead
Change-Id: Iad2a5d4655ad116e85ea3ea98bc209b37cbdba39
Reviewed-on: https://gerrit.instructure.com/202619
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
doesn't worry about the creation of users, only returns
whether the users are found or not and whether there
are multiple matches across the trusted accounts
(doesn't try to prioritize one or the other, instead letting
the user decide which user to add)
also only uses one search method so it's more explicit how
we're trying to find users
how to use:
similar to current user list,
post to /courses/X/user_lists.json
with a 'user_list' text parameter
but add additional parameters
- 'v2' set to 1 or true
- 'search_type' set to either
'unique_id' (login ID)
'sis_user_id' (also searches integration id because why not)
'cc_type' (searches email addresses and sms phone numbers)
closes #CNVS-32175
Change-Id: I175e49a93525674ae97a067b9e8443812fa964f0
Reviewed-on: https://gerrit.instructure.com/91430
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
QA-Review: Heath Hales <hhales@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
fixes CNVS-28101
test plan:
* as an account admin (not site admin), try to add a site admin to a
course via the UI
* it should not find the site admin
* try again as a site admin (adding to the same course that's not
part of site admin)
* it should work
Change-Id: Ib2502a1a0a35bee331d92d06f5d92e1d8762c226
Reviewed-on: https://gerrit.instructure.com/74755
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs #CNVS-21596
Change-Id: I1231665cc40c039bf036a853579cebdb34cb8617
Reviewed-on: https://gerrit.instructure.com/58691
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
test plan:
* create a user on Site Admin account with a
name + email
* edit the user's login to give it an SIS ID
* create a user on a local account with a
different name + email
* edit the user's login to give it the same
SIS ID as the previous user
* try to add a user to a local course by
searching by the SIS ID
* should find the local user (not the Site
Admin user)
closes #CNVS-19626
Change-Id: Id970023c079010080a1d7a8d93a4494a10bbd7c6
Reviewed-on: https://gerrit.instructure.com/51634
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
refs CNVS-18296
in case global lookups is enabled, but not populated; this fixes
that problem while not added any extra load in 99.99% of happy
cases
test plan:
* configure global_lookups, but don't populate them
* adding an existing user to a course should still
work
Change-Id: If3012ee5e8b4bd2d79bee840fc1250fc43b7f186
Reviewed-on: https://gerrit.instructure.com/48796
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
test plan:
* use the course users page to add users
with names that include unicode characters
(such as accents)
* should not fail with "unparseable" errors
closes #CNVS-15085
Change-Id: Ieee80adbabed05f42aab8040c4351e35b680a75e
Reviewed-on: https://gerrit.instructure.com/41766
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
refs CNVS-9939
it's not an exact match, so it won't work
Change-Id: I7ab20a0e9bbbd6f8b06079addcb3baf5362788fa
Reviewed-on: https://gerrit.instructure.com/27814
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-9085
test plan:
* login using site admin credentials at the default account
* via the UI, enroll a site admin via login, sis id, and e-mail
address in a course
Change-Id: If525949d4da780e4750ecf53f7acd8aa5440387e
Reviewed-on: https://gerrit.instructure.com/26729
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs CNVS-7597
given Object#to_json's default implementation, the old to_json
overrides follow from the new as_json overrides. and now we can also
call as_json and get the expected non-serialized data.
test-plan: N/A
Change-Id: Ia57562e0c73752a13023cad4ef6bae9435790bee
Reviewed-on: https://gerrit.instructure.com/23647
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
test plan:
* create a user and login with a sis id
* confirm that the user can be added to a course
through the course 'People' page, by including
their sis id in the list (just as with the login id)
closes #CNVS-7086
Change-Id: Ia4369ba5e78083c233b3921aa1b9246f2db6824e
Reviewed-on: https://gerrit.instructure.com/22647
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
This also refactors the UserList constructor to better support passing this
information in when a user is being created through an invitation.
Testing Steps:
=========
* In a course, go the Settings > Users tab.
* Under "Add Course Users", select a type (ex: "Students") and
give the user information.
* Ex: "Student Test" <studenttest@example.com>
* After adding the user, verify in the console that the user has
the correct initial_enrollment_type. (As far as I know, this
information isn't displayed anywhere)
* Sample console script:
* u = User.last
* u.initial_enrollment_type #=> "student"
Can verify that this works for the following supported types
"student", "teacher", "ta", "observer".
Anything else (like Designers) doesn't get stored.
Change-Id: I5d900c421a04e95b5b92e21cd57e7694d1e98958
Reviewed-on: https://gerrit.instructure.com/14110
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan:
* have a site admin user in shard 1
* add that user by their login id as an admin to an account in
shard 2 (in the UI)
* it should work
* repeat for enrolling in a course
Change-Id: I403f0f853056d4ea1dd9628c70e882fdc3cfd8bf
Reviewed-on: https://gerrit.instructure.com/14090
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
allow users to join, or request to join groups and leave groups they are part
of, if the group allows those actions. allow moderators to invite others
to the group by email address. allows moderators to add or remove moderator
privleges of other group members.
test plan:
- no ui yet, so try these api actions manually and make sure they do the right
thing.
Change-Id: I2765f07acb131e503add67b0daa37f18fdbde6c2
Reviewed-on: https://gerrit.instructure.com/11229
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#7838
test plan:
* add an admin to an account by searching for "allfjaldjsf" (or some
other random string)
* it should say the user could not be found
Change-Id: I2a2da0790ed64cacf01229b10f3bc7059b1431ad
Reviewed-on: https://gerrit.instructure.com/9855
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#7422, #7151
test plan:
* create a user with a login id that's a 10 digit number
* you should be able to add that user to a course
* enable open registration
* create a user with a login id that's an e-mail address. add that
e-mail address to another user.
* you should be able to add specifically the first user by using
the e-mail address
Change-Id: Ia84658f023f5017cf5f5a635ee737afd4e4ab7c0
Reviewed-on: https://gerrit.instructure.com/8979
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
closes#7059, #7411
preferred is a compromise between open registration and closed
registration. if a single user is found, that user is found without
introducing any temporary user to allow user disambiguation. if no
users are found, or multiple users are found, it's the same behavior
as open registration.
as part of this, the "only search existing users" checkbox has been
removed. instead, preferred searching will be used in the following
cases:
* adding an admin, and open registration is enabled
* adding an admin, open registration is disabled, and the user
has permission to create new users
* adding a user to a course, open registration is enabled, and
delegated authentication is in use
* adding a user to a course, open registration is disabled, and
the user has permission to create new users
the notable case that preferred searching is not used, and the
user would want to use search existing users is open registration
enabled, and adding a user to a course. in this case, a temporary
user will be created instead of sending the invitation to the
existing user. however, the end user experience is identical
(invitation sent to e-mail, invitation visible in the same locations
in the UI), with the small exception that the end user gets the
opportunity to create a separate account if desired (but not
preferred).
test plan:
* go through each of the cases above for a user that doesn't exist
yet, a single matching user exists, or multiple users exist.
it should behave as described above
Change-Id: Idbc7fe23bfc7430b4cd25f7981f5dc08b9e4ffda
Reviewed-on: https://gerrit.instructure.com/8966
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* need to have accounts that don't trust each other (i.e. from a
plugin)
* create a user in account A with an SMS channel. Disable open
registration in account B. You should not be able to add the
user from account A by SMS.
Change-Id: Ic68527cab1d0f581281fe8344583cfe10905f63a
Reviewed-on: https://gerrit.instructure.com/7264
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
refs #6533
this covers both the case of multiple pseudonyms from different accounts,
or multiple pseudonyms in a single account when looking up by email
test plan:
* disable open registration
* create a user with multiple pseudonyms, and a non-matching email;
you should be able to find and add the user by their e-mail
* create a user with (matching) pseudonyms in account A and B; you
should be able to find and add the user in account C by their
existing pseudonym(s)
Change-Id: I89ce34a6a36dc7c534b35386551865b56e71bf7f
Reviewed-on: https://gerrit.instructure.com/7263
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
* disable open registration in all accounts you use
* create users with the same login in multiple accounts, and invite
user to a course in one of the accounts; it should find the user
from the account the course is in
* create users in the same login in multiple accounts, and invite
user to a course in an account that does not have that login; it
should not find any users (can't resolve the conflict)
* if you have a plugin the changes the definition of a trusted
account, try to add user from one account to an account that does
not trust the first; it should not find any users
Change-Id: I5e5283e8f41bb0aea00ae3a48e4dc87a7e811978
Reviewed-on: https://gerrit.instructure.com/7258
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
this case happens when open registration is disabled, the user's
pseudonym does not match their e-mail address, and the user is
invited via their e-mail address
test plan: do the above, and it should not create a temporary user
Change-Id: Ibf864d25f94d6436f1ebc5b9486eb0df8ca28d6c
Reviewed-on: https://gerrit.instructure.com/7014
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
also add a checkbox for admins to only search for existing users
(i.e. ignore open registration)
Change-Id: I84d2ba7992339b37506e41a50c336325af0ac73b
testplan:
* add a student to a course as a TA
* add a user to an account or a course as an admin, with and without
open registration, with and without manage_user_logins permission,
with and without checking "search only existing users" (not all
combinations applicable, each underlying condition is checked in
specs)
Reviewed-on: https://gerrit.instructure.com/6969
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>
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>
Cody Cutrer