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>
James Williams