test plan:
* have a course with a student and observer
in the same section
* set the student enrollment to restrict them
from viewing users outside of their section
* the student should not now be able to see
the observer in the course user list
closes #ADMIN-1574
Change-Id: I02f25f75edcc7d99eba6967054561b26488fea0b
Reviewed-on: https://gerrit.instructure.com/170050
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jeremy Stanley <jeremy@instructure.com>
Product-Review: James Williams <jamesw@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>
should now only check for the requested permissions instead of
all of them
also don't touch the user every time conversations is loaded
test plan:
* searching for recipients on the conversations page should
work as before
closes #CNVS-28094
Change-Id: I3b67663003de94fa4e71b0f2de0aeea280be39d6
Reviewed-on: https://gerrit.instructure.com/75857
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
closes #CNVS-26031
Change-Id: I2e0351fb62e5a06b47fe8c6c3dd503318d29a7ad
Reviewed-on: https://gerrit.instructure.com/69228
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
refs #CNVS-21596
Change-Id: Ib41c03782b1667d3876283fd99d8ccf7585e1fd6
Reviewed-on: https://gerrit.instructure.com/58651
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes CNVS-18578
test plan
quauntitative functionality test
- regression test recipient picker when picking in groups
qualitative speed test
- have a high enrollment user with normally slow response times
during conversation recipient finding
- compose a conversation message
- search for recipients in a group using the dropdown recipient
picker
- ensure that the response time for the recipient is not as bad
as it was
Change-Id: Ie7655544f93d1168ac78f0b1497c1bec9f0319c6
Reviewed-on: https://gerrit.instructure.com/49395
Tested-by: Jenkins
Reviewed-by: Matthew Wheeler <mwheeler@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
test plan: simple regression test on search functionality
on course People page
fixes CNVS-15507
Change-Id: I6bdf9a668a232c55e565d6085eeb63776f68c1a6
Reviewed-on: https://gerrit.instructure.com/45548
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: James Williams <jamesw@instructure.com>
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
test plan:
* create a course with multiple sections
* create a calendar event with "Use a different
date for each section" checked, and a different
data assigned for each section
* enroll a student in a course in one of the sections
* add an observer for the student
* view the course syllabus as an observer
* should see the specific section's event date (just
like the student)
closes #CNVS-15485
Change-Id: I6ed751d27506cf9548f56cbdfc17506b080c398b
Reviewed-on: https://gerrit.instructure.com/44817
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
associations with joins were never really supported by rails
test plan:
* canvas works
Change-Id: I62dd9b38c7340fce96351f1e3ba91acd6440aa66
Reviewed-on: https://gerrit.instructure.com/42856
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Fixes CNVS-16369
Test Plan:
1) Create a large dataset locally. One way from a rails console:
```
c = Course.last
(1..6).each do |n|
gc = GroupCategory.create!(context: c, name: "Name#{n}")
(1..200).each do |m|
Group.create!(name: "Name#{m}", group_category: gc, context: c)
end
end
GroupCategory.last(4).map(&:destroy)
```
2) On Master, see that the load time for the course users page (everyone tab) is long. 14 seconds in my case.
3) On this branch, see that the load time is much much shorter, 6 seconds in my case.
Change-Id: Ic68ef085e56a69b972cdb8069bc15cda4bd2c112
Reviewed-on: https://gerrit.instructure.com/43163
Reviewed-by: Joel Hough <joel@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Matthew Wheeler <mwheeler@instructure.com>
fixes CNVS-15797
test plan
tl;dr - regression test recipient finder, it should be faster for
sections
- as a teacher with many courses in many accounts (10ish? as long
as it usually causes a delay in the address book), begin composing
a message in the conversations inbox
- select a course from the context dropdown
- using the recipient finder, select 'Course Sections'
- select a section
- ensure that the delay between selecting the section and seeing
the section users is less than before this commit
- ensure that the section user list has the same contents as
before this commit
Change-Id: I5ede3d05c25580d9cb354dfd5a4bd03ed6a2e440
Reviewed-on: https://gerrit.instructure.com/41755
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brad Horrocks <bhorrocks@instructure.com>
Reviewed-by: Mark Severson <markse@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
it's a shim of the rails 2 variety, and breaks in rails 4 in the
common case because the options became a scope
Change-Id: I712a8fed35ee0a9747a13c1495f7d51b8dac6823
Reviewed-on: https://gerrit.instructure.com/41716
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
test plan:
- Create a course via SIS import or Accounts page
(not via front page, since this will enroll you as a teacher)
- Go to the settings page for the created course and verify
no sections were created
fixes CNVS-10683
Change-Id: I4ee7296cf45b44335a5fc49d701951e079800b20
Reviewed-on: https://gerrit.instructure.com/29189
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
fixes CNVS-4806, CNVS-4482
test plan:
* open conversations
* compose a new message
* select a course
* verify that you can search for a section in the course by name
* verify that you can search for a group in the course by name
* verify that you can send a message to an entire group if you have
permissions to send it to the entire course
* create a course with two sections
* add students to the sections and add a TA who can only see
students in one section
* masquerade as the TA
* verify that the other section does not appear in the recipient
search section list
* verify that users in the other section do not appear in the
recipient search student list
* create a course in a concluded term
* open new conversations
* verify that the course is listed in the concluded section of the
filter list
* masquerade as a teacher for the course
* open old conversations
* verify that the concluded course is present in the filter search
* verify that the course is not present in the recipient search
Change-Id: I5a4e62de4e182cf0859dc47a3f8ad694f616a3bc
Reviewed-on: https://gerrit.instructure.com/27433
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Product-Review: Braden Anderson <banderson@instructure.com>
test plan:
* after adding, updating or deleting a course section:
* on the people page, for a student, click on "Edit Sections"
* should use the updated sections
fixes #CNVS-6034
Change-Id: I91d402f77637d4097b5ecb2a8d8064842b28bf7e
Reviewed-on: https://gerrit.instructure.com/21834
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
fixes CNVS-4289
test-plan:
* create a user on shard 1
* create a course on shard 2 with multiple sections
* enroll the user in the course as a teacher (so he can see both
sections)
* go to the user's inbox
* should not get a page error
Change-Id: I9d584835f697ddef1e59a44d11797add51367b6c
Reviewed-on: https://gerrit.instructure.com/18189
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
adds new "Send messages to the entire class" permission, which defaults
to off for students. controls whether or not the "Select All" checkbox
and the checkboxes next to Everybody/Teachers/Students/etc. are
available in the recipient finder.
test plan:
1. As a teacher, confirm that the Everybody/Teachers/Students/Select All
checkboxes are available in any courses you teach
2. As a student, confirm that the Everybody/Teachers/Students/Select All
checkboxes are not available in any courses where you are just a
student
3. In course permissions, let students "Send messages to the entire class"
4. Confirm that students now see all those checkboxes
Change-Id: I5bca82414dc6e1e2f19abdd2e3257ca935d6f2c4
Reviewed-on: https://gerrit.instructure.com/17519
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
no functional changes, just reorganizing things. needed for #7277
test plan:
1. all conversation specs should pass
Change-Id: If380ca04942e2923401a0de1883386c67199a832
Reviewed-on: https://gerrit.instructure.com/13616
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
now that we also cache group permissions (in addition to course ones),
start grabbing the permissions in load_all_contexts. although we cache all
of them, only return ones that are requested (to keep js ENV etc. small)
slight refactor of conversations around permission stuff, and added the
ability to specify an :if check for a permission (i.e. the permission is
only on for a user if the policy says so *and* the :if method returns
true)
test plan:
n/a, see specs (new one, plus existing ones that exercise
load_all_contexts in its various capacities)
Change-Id: I82f4f71edf221c6c859a15156224d8e5b719edc5
Reviewed-on: https://gerrit.instructure.com/12983
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fix issues in the new course roster management UI around admins who are
not enrolled in the course. specifically, we now:
1. show admins the sections the users are enrolled in
2. allow admins to manage the sections users are enrolled in
3. allow admins to re-send invitations
4. allow admins to add students to an observer
test plan:
1. as an account admin, go to the course settings page for a course you
are not enrolled in
2. confirm that you see the section(s) that each user is enrolled in
(below the email address)
3. confirm that you can add/remove users' enrollments in particular
sections
4. confirm that you can re-send invitations (both for those that have and
haven't accepted)
5. confirm that you can add/remove students to/from an observer
6. as a general regression test, perform steps 2-5 for a teacher that is
enrolled in the course
Change-Id: I3c67896e941000689860b8c0924df33bdd48f921
Reviewed-on: https://gerrit.instructure.com/12738
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
other changes:
- makes it possible to add a student to multiple sections in the course
- pagination of the user lists
- converted user tab js to coffee and backbone
test plan:
- as a teacher go to /courses/*/settings#tab-users
- verify that multiple students can be linked/unlinked to an observer
- verify that users can be added to and removed from multiple sections
- verify that 'Resend Invitation' and 'Remove from course' work
Change-Id: I0f64f72f1937348817990b6f13b6310185b68a73
Reviewed-on: https://gerrit.instructure.com/10865
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
James Williams