fixes CNVS-35217, CNVS-35799, CNVS-35800
- allow Services::AddressBook.known_in_context to take a whitelist of
user_ids. enables...
- allow address_book.known_users to take a context parameter (replaces
include_context; see note below). enables...
- use known_users(users, context: ...) when normalizing recipients in
the conversations controller, in place of post-filtering results from
known_in_context(context, maybe_admin).
- remove is_admin flag from address_book.known_in_context; admin view
never utilized for this method
- also remove is_admin flag from address_book.search_users; admin view
is determined implicitly when context parameter present
- move admin_context checks from conversations controller and search
controller inside the address book
- don't apply read_as_admin check when evaluating params[:context] for
visible contexts in search results (it wasn't intended for that, only
for @admin_context, which is gone)
- finally, make passing of contexts consistent; all of known_users,
known_in_context, and search_users allow asset_strings _or_ context
objects
note on include_context: include_context was intended to force inclusion
of participants in an otherwise unconnected context for an externally
vetted admin, without restricting other contexts. the context parameter
is instead intended to restrict to participants known either through
that context, or as an admin over that context while other contexts are
ignored. this is more consistent with how the call was being used.
meanwhile, whether an admin view is appropriate for that context is
determined within the address book instead of by the caller.
when determining whether a context is eligible for admin view within
known_users or search_users, the sender must have read_as_admin
permission on the context _and_ not be a participant in the context's
course (if any). this allows restrictions due to the course
participation to override read_as_admin, as they should.
test-plan:
[CNVS-35217]
- have an account with an account admin
- have a course in that account with two teachers (one section-limited,
one not), and a student in a different section than the
section-limited teacher (all active, published, etc.)
- ingest the data into the address book service and configure canvas to
use the service
- as the account admin, search for the student in the inbox in the
context of the course; should find them.
- as the non-section-limited teacher, search for the student in the
inbox in the context of the course; should find them.
- as the section-limited teacher, search for the student in the inbox in
the context of the course; should not find them.
[CNVS-35799, CNVS-35800]
- add two more students to the same course, then remove one from the
course and deactivate the other
- re-ingest the data into the address book service (or have had the
kinesis stream hooked up during the change)
- as the non-section-limited teacher, search for the student that was
added but then removed; should not find them
- as the non-section-limited teacher, search for the student that was
deactivated; should not find them
- as the account admin, search for the student that was deactivated;
should not find them
Change-Id: I3233d8d45394c9233adc9888bfaf477e73bfde11
Reviewed-on: https://gerrit.instructure.com/107053
Tested-by: Jenkins
Reviewed-by: Andrew Huff <ahuff@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
closes CNVS-34528
another option for the address book strategy chosen in the plugin.
combines answers from current MessageableUser implementation with
traffic directed to the service as if it were in use. but the service is
instructed via `ignore_result` parameter to reply to canvas as quickly
as possible, so that if the service does have performance issues, actual
canvas performance is not affected.
test-plan:
- set up canvas to be able to talk to the address book service
- have a published course with an active teacher and an active student
- do _not_ replicate that data into the address book service; i.e. the
service answer should be wrong if used
- choose the "AddressBook performance tap" as the address book
implementation in the plugin setting
- logged in as the teacher, query for the student in the inbox. should
find the student (backed by the messageableuser implementation)
- check the service request logs; even though the service response
wasn't used, there should still be a request made against it
- take down the service entirely
- repeat the query in the inbox. should still get the result from the
messageableuser implementation despite the service being unavailable
Change-Id: I031b7c397d2e20d74d7699a81ca8040064a8df75
Reviewed-on: https://gerrit.instructure.com/104112
Reviewed-by: Andrew Huff <ahuff@instructure.com>
Tested-by: Jenkins
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
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>
Landon Wilkins