closes CNVS-29869
refs CNVS-31303
adds an implementation of the AddressBook facade backed by an external
address book service. cleans up some implementation of the facade to
faciliate that.
intentionally punts on pagination through the service for right now.
that will be covered in a later commit addressing CNVS-31303.
test-plan:
- depends on having an address-book service that fulfills the expected
contract
- if using consul, add the host for your address-book service to
config/consul.yml (see config/consul.yml.example)
- if not using consul, add it to config/dynamic_settings.yml (see
config/dynamic_settings.yml.example)
- go to your canvas' /plugins/address-book and configure your account
to use the service implementation
- smoke test the inbox address book UI in canvas
Change-Id: I4e89bd7c2ac64b5a4902905cbdd37c8283f7adf5
Reviewed-on: https://gerrit.instructure.com/88431
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
Tested-by: Jenkins
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
closes CNVS-29825
test-plan:
- before enabling plugin setting, address book should function normally
(via MessageableUser)
- enabling plugin setting and explicitly choosing MessageableUser
strategy should allow address book to function normally
- enabling plugin setting and explicitly choosing Empty strategy should
not produce any page errors, but should cause all users to have an
empty address book (don't actually create any conversations in this
state or you'll end up with have zero-participant conversations)
- re-disabling plugin setting should cause address book to function
normally through MessageableUser again
Change-Id: I45848fd51bccef4d4a3d8d6ddad85b7c54582aa2
Reviewed-on: https://gerrit.instructure.com/87164
Tested-by: Jenkins
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
fixes CNVS-29824
refs CNVS-29862, CNVS-29867
test-plan:
check for regressions around:
* accessing profile#show endpoint, with profiles enabled, is
authorized if and only if current user knows profile owner.
* eportfolios#show, with profiles enabled, includes link to owner's
profile if and only if current user knows owner.
* conversations:
- filtering of individual recipients when creating a conversation
- expansion of context recipients when creating a conversation
- restriction of individual recipients to those known via course
when creating a conversation in a course
- including as an admin over that course
- filtering of individual recipients when adding a message to an
existing conversation allows existing recipients
* searching/browsing address book (conversation creation, link
observer to students, due date overrides, etc.):
- when loading info about single user (user_id parameter), including
combinations of conversation_id and context parameters, returns
user data if and only if the target is known to current user under
those parameters
- users matched:
- excludes already listed users
- restricts to users known via specified context, if any
- including as an admin over that context
- finds users with weak associations (e.g. invited student that
hasn't logged in for first time yet) when linking observers
- doesn't find users with weak associations otherwise
- contexts matched:
- limited to those known to current user
- have count of known users
- have counts of known users in synthetic contexts
* data returned for known users in various API calls include common
course and groups between current user and returned user
Change-Id: I66bca0921b298be8d529a713fa982a6dfdcbcc8e
Reviewed-on: https://gerrit.instructure.com/84045
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
Tested-by: Jenkins
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
Jacob Fugal