[skip-stages=Flakey]
auto-corrected for the most part, but I went through specs and used
the have_key matcher when possible
Change-Id: I4a2df1cdd536a94f3b493668386883d1148660c9
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/278050
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
refs FOO-1125
flag=non
TEST PLAN:
1) stats for things like ImperiumTimeouts should still
end up in datadog
2) sentry errors for the target error types should disappear
Change-Id: I6e97c04e3f6fcc3545b10418511934c89f20a419
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/251536
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>
fixes USERS-539
flag = none
test plan:
- As an admin not enrolled in the course
- Navigate to the People page
- Have two different course sections with enrollments
- Click the hamburger menu for a user and select
the 'edit sections' option
- Search for the section for which the user is not enrolled
- Verify it returns the proper Section enrollment count
that is non zero
Change-Id: Ib4e910878651fb80a450258237e43c56138dd528
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/239597
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
Product-Review: August Thornton <august@instructure.com>
refs USERS-430
flag=none
test plan:
- tests pass
-- OR --
- create a siteadmin user with a token
- use the token to create a conversation
- ie POST http://localhost:3000/api/v1/conversations
- all recipients should be users you have no association with
qa risk: low
Change-Id: Id54eac5901ea59f281f08ebbc4d0b58d72f36266
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/231216
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Daniel Lee <dlee@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Davis Hyer <dhyer@instructure.com>
fixes COMMS-1308
When students are restricted to viewing only members of their own
section, and a group contains students from different sections,
students cannot send a message in Conversations to their group
members in a different section when the class is selected as the
context rather than the group itself. This commit allows students
to send a message to a group member in a different section when a
class is selected as a context.
Test Plan:
* Create a course with two sections; select the option that
prevents students from communicating with students in a section
other than their own.
* Create a group that contains students from both sections.
* Masquerade as a student that belongs to the group; compose a
message in Conversations. In the "course" form, choose the course
that you just created. In the "To" form, click on the address
book icon; select Groups; select the group that the student
belongs to; and select a student in the group that belongs to a
different section than the student you're masquerading as
* Fill in subject & content; send the message
* The message should send with no errors
Change-Id: I0c0ab55d37b2c01d9dfa3a71d1f8940e565df600
Reviewed-on: https://gerrit.instructure.com/200187
Tested-by: Jenkins
Reviewed-by: Ryan Norton <rnorton@instructure.com>
QA-Review: Ryan Norton <rnorton@instructure.com>
Product-Review: Michelle Simmons <misimmons@instructure.com>
Fixes issue with address-book "performance tap" plugin setting.
Test Plan:
* Navigate to "/plugins/address_book"
* Select "AddressBook performance tap" from "Answer address book
queries through" option and click "apply"
* Navigate to Inbox and compose new message
* Message should send without issue (previously gave "unexpected error
ID: ###" message)
closes CNVS-38284
Change-Id: I12d5dd50f716128d44599993152a4bf91e78555d
Reviewed-on: https://gerrit.instructure.com/119752
Tested-by: Jenkins
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jonathan Featherstone <jfeatherstone@instructure.com>
refs CNVS-37900
with the old MessageableUser implementation, the behavior is identical.
but when using the service, it allows using one HTTP request against the
service's new /recipients/counts endpoint instead of multiple HTTP
requests against the deprecated /recipients/count endpoint
test-plan:
- enable the address-book service
- a query that involves multiple contexts in the result still gets
counts for each of those contexts
- said query is faster, making one request for counts to the service
instead of one each
Change-Id: I2793984f00247b3af3ebb8ba9ab559b38889c045
Reviewed-on: https://gerrit.instructure.com/117677
Tested-by: Jenkins
Reviewed-by: Andrew Huff <ahuff@instructure.com>
QA-Review: Jonathan Featherstone <jfeatherstone@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: Jonathan Featherstone <jfeatherstone@instructure.com>
don't need to preload users that are already in the cache. not
functionality change, just performance
test-plan: N/A
Change-Id: I34aecd97a35619718a7c66c902974d3b2cec09ae
Reviewed-on: https://gerrit.instructure.com/109287
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
Tested-by: Jenkins
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
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-34484
address-book service recently updated with pagination info available. in
the process, the shape of its response also changed. update for that
change in shape, and capture the pagination info it returns into the
bookmarker so it can be used for pagination here on canvas' end.
test-plan:
- have a published course with a teacher and >10 students
- have the address-book service running, your canvas configured to use
it, and your canvas' data ingested into the service
- as the teacher, got to conversations and start a new message
- in the recipients field, open the address book and drill into that
course's students
- should see all the course students (page traversal is happening
transparently)
- should see multiple requests in the address book service's logs
Change-Id: I665ac77d01d93e74ac41f6291b4dc698c0446429
Reviewed-on: https://gerrit.instructure.com/100273
Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Tested-by: Jenkins
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>
Cody Cutrer