fixes a problem caused by changing the users#show
to check rights granted by the user
rather than the context, which caused a account user
with global :view_statistics permission
to not be able to view the users
test plan:
* add an account user with a role that grants permission
to view statistics, but not manage_users (i.e. "add/remove
students")
* make sure they can visit "/users/:id" for a user
enrolled in a course under the account
fixes #CNVS-4575
Change-Id: I9bafbd015d7057a583501b836677b687df01bdd4
Reviewed-on: https://gerrit.instructure.com/18537
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Adam Phillipps <adam@instructure.com>
test plan:
1. visit /courses/:id/people
- users should populate the page
2. scroll down
- should lazy load next pages
3. enter a search term
- should render results
4. scroll down
- should lazy load large result sets
Change-Id: I20b2aa2ec5dab74053b78340ac9d2920b0521e8b
Reviewed-on: https://gerrit.instructure.com/18447
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
This needs to check the user, not the account, but we no longer grant
:view_statistics if a user has :read_reports on a course, effectively
blocking teachers from viewing the top-level user page by default.
A new user-level :read_reports permission was added so that teachers and
account admins can still view the teacher/student interaction reports as
before, even though teachers don't have :view_statistics
fixes CNVS-2964
test plan:
- a site admin user should be able to view /users/X on any account
- an account admin user should be able to view /users/X for students in
thier account, but not in other accounts
- a teacher should not be able to view /users/X for a student in their
course Y, but they should be able to view /courses/Y/users/X
Change-Id: Iebc639bd935f50344cb77614f6eeae2bacb421e2
Reviewed-on: https://gerrit.instructure.com/18473
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Bryan Madsen <bryan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-1171
test plan:
* full conversations regression test
* initiate a conversation with a user from another shard
* reply to that conversation from both the sender and the
receiver
* repeat for a group conversation involving two or more
shards
* repeat for huge batch conversations with hundreds of
users and two or more shards
* known NOT working yet:
* re-using the correct cross-shard private conversation
* probably the tagging of messages with Course x,
Group y, etc.
Change-Id: I52549039875941cd518077cea4e28bfd2bc10dbf
Reviewed-on: https://gerrit.instructure.com/16523
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs #CNVS-1959
remove session interaction, everything is
now tracked with parameters. Also
removed the "confirm_merge" action which
does not appear to be used.
Test Plan:
1) login as an admin
2) try to merge two users together
3) as long as the users being merged are
not the same user, you should not get a warning
about how the user cannot be merged with itself.
(naturally, if you DID try to merge a user
into itself, you absolutely should receive
that warning)
Change-Id: I98fdb925b3f6d14b4de98737f9af8b6093312847
Reviewed-on: https://gerrit.instructure.com/16692
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
basically use ids, not uuids
test plan:
* as a site admin
* go to a user
* click "merge with another user"
* in the id field, put in a global id
* it should pull up that user
* finish the merge
* it should succeed
Change-Id: I11f6a2e989f8342d748c5a7ba63aac414f340ca4
Reviewed-on: https://gerrit.instructure.com/15366
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
If avatars are enabled for an account then when we show
avatar images it should default to our silhouette instead
of a blank 1px-wide image. This will allow us more
reliability when laying out content that uses avatars.
test plan:
- enable avatars for the account
- load a discussion where users don't have avatars
- make sure silhouettes appear correctly
- disable avatars for the account
- load the same discussion
- make sure silhouettes don't appear
Change-Id: Iec96b163365a20b27b9f637a23917699fb13102e
Reviewed-on: https://gerrit.instructure.com/9023
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
don't list courses multiple times on the user grades page if that user has
multiple enrollments in a course.
test-plan:
- as a student with multiple enrollments in a course and enrollments in
> 1 courses
- visit /grades, make sure courses are listed once.
Change-Id: Icd3722ba07070fc6453e7395a833c701c447860f
Reviewed-on: https://gerrit.instructure.com/9247
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fix regression from #5618 where we stopped passing along the fallback
for conversation avatars.
also fixed it so we always respect the fallback, host/scheme, and
domain account avatar setting. previously we would cache the first one
for a given user, to the detriment of any subsequent requests for that
user (e.g. conversations uses the default fallback for the recipient
finder, and a custom one for everything else. without this change,
whichever one got requested first would win and get cached as the
gravatar fallback).
test plan:
setup:
* make sure you have avatars set up on various users (some submitted,
some approved)
stuff from #5618:
* make sure the old style of avatar image urls still work
* go to a page with user avatars (like discussions)
* make sure avatars appear correctly for users with avatars
* put in a bogus URL ("/images/users/a")
* make sure it doesn't die
* put in a bogus URL with a hyphen ("/images/users/1-1")
* make sure it doesn't die
then test conversations:
* go to conversations with avatars enabled
* ensure that you see the appropriate gray silhouette for users
without a gravatar in the conversation/message panes
* ensure you see the alternating gray/white silhouette (depending
on focus) for those users in the recipient finder (it's actually
the blank image, the silhouette is a background image behind it)
then test hostname and account setting fu:
* log in under a different domain (e.g. 127.0.0.1 instead of
localhost) and go to discussions
* ensure that the fallback image is served up from the current domain
* change the avatar setting to enabled_pending
* ensure that you only see approved avatars (see initial setup)
then test cache invalidation:
* approve a pending avatar
* ensure the avatar now shows up under all domains
Change-Id: I9cd007463e3cb4a302b1986f9d4bb61fe16799ac
Reviewed-on: https://gerrit.instructure.com/9130
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
allow admins to view interaction reports on concluded courses, and include
concluded enrollments in the interaction reports.
test-plan:
- create a course with a concluded student
- should be able to view interaction reports from course user page
- conclude the course
- as an admin, should be able to view teacher activity report for teacher.
Change-Id: I8722ca86a5836da03994db31e5c7753a86516824
Reviewed-on: https://gerrit.instructure.com/9107
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* go to /images/users/<id> for a user without an avatar set,
but avatars are enabled
* you should end up back on the same host, with ssl
* change your avatar on the profile page
* the fallback to dashed should also be over ssl
Change-Id: I3e3cd322e75c2bd7a329c39887043915f80d2112
Reviewed-on: https://gerrit.instructure.com/8956
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
enrollments previously had attribute
"limit_priveleges_to_course_section," but should
be spelled "privileges." replaced spelling in a
migration and across app.
affects: enrollments model
test plan:
* run specs
Change-Id: I15dcf9a023ead9bb1aed42abc2d1a7c233610840
Reviewed-on: https://gerrit.instructure.com/7431
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
create a user with a sortable name other than what is automatically
inferred; make sure it displays correctly in the users list for the
account
Change-Id: I12528436571ffdd211d6d2719eb1789d9afffdd2
Reviewed-on: https://gerrit.instructure.com/6732
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
this was silly of me, the super-short names i was checking for were
generic enough that i saw a failure when /s1/ matched part of the
authenticity token on a form
Change-Id: I9d3ccc1cc2197cbe2b9bdde9578118abf2243375
Reviewed-on: https://gerrit.instructure.com/4557
Reviewed-by: JT Olds <jt@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Mark Severson