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>
Cody Cutrer