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