fixes FOO-1898
[ignore-stage-results=Flakey Spec Catcher]
this commit touches known flakey specs,
but does not make them any flakier
if they have open registration off, we need to trust the SIS
if open registration is on, we ignore unconfirmed anyway, and
just create a new temp user that will get merged together
test plan:
* have open registration *off*
* add two users with confirmed email addresses (via SIS, etc.)
* log in as one of the users, and go to your profile
* add the other user's e-mail address (but don't confirm it,
since in reality you couldn't)
* log in as a teacher or an admin
* add a student to a course with the duplicated email
* it should only find the confirmed user
* add the user as an admin
* same result
Change-Id: I0a64c45876d7f49e3662f55496e76c5c37306376
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/265171
QA-Review: Ahmad Amireh <ahmad@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Ahmad Amireh <ahmad@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
closes FOO-1383
flag=none
TEST PLAN:
1) try to use a seach_type of "nonsense"
2) you get a 400, not a 500
Change-Id: I901ded4c2cbc1106f322ca9ee8bbe389131162b2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/255697
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: Simon Williams <simon@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>
fixes CNVS-38767
test plan:
* in a group of associated accounts, each on different shards
* create a user in one shard/school (A)
* add a login for that user to a school (B) on a different shard
(preferably with a different login ID than their login to
school A)
* in school B, go to add a user to a course, and search by
the user's e-mail address
* it should find the user, and show their login and institution
as being school B
* if you search by login ID instead, and search for their school
A login ID, it will show they're from school A
Change-Id: I60e0d204169ba42c7a6dd3d5dad5080c269809f7
Reviewed-on: https://gerrit.instructure.com/123385
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-35919
also, prefer SIS pseudonyms over non-SIS pseudonyms from any given
account
test plan:
* have a non-SIS pseudonym and a SIS pseudonym on a user
* do an LTI launch
* the LTI tool should get the info from the SIS pseudonym
Change-Id: I60a3c48a32eae94db93b0e72f1f0f6c5b6a5f5c2
Reviewed-on: https://gerrit.instructure.com/107785
Reviewed-by: Nathan Mills <nathanm@instructure.com>
Reviewed-by: Tyler Pickett <tpickett@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
fixes a problem caused by two matching cross-shard
communication channels that happen to belong to the
same user. it tricked the code into thinking there
was a duplicate result but then broken when trying
to find the "other" user
closes #CNVS-35649
Change-Id: I61c555ce563a684d9579747a38a9758515bdbb1a
Reviewed-on: https://gerrit.instructure.com/105155
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@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>
Cody Cutrer