fixes CNVS-10713, CNVS-10636
test plan
- ensure that every page that has avatars displays them in a
consistent, circular way
- ensure that the change didn't break the rest of the page
avatars were left square on purpose on these pages
- speedgrader header (too much work to circle)
- big pic on profile page (too big and interactive, needs
some proper ui design)
- profile pic selector (not really profile pics yet, just images)
- app review (error handling is tricky)
some pages where you might find avatars to check
- manage avatars (/account/:id/avatars)
- discussions index
- discussions show (don't forget threaded sub-entries!)
- profile page (/about/:id)
- group edit (i can't find this page, but it has code)
- course roster (/courses/:id/users)
- context roster (/groups/:id/users)
- old conversations (message list, message detail, people picker)
- new conversations
- gradebook2 (student column, submission comments)
- speed grader (top left student name, submission comments,
discussion assignment)
- app review (enable app center plugin, app rating comments)
- user show page (/users/:id)
- masquerade page (/users/:id/masquerade)
- masquerade footer (on the bottom of any page when you masquerade)
Change-Id: Ic01a4b44433aaf6254798d8267bf473a8bf85c2d
Reviewed-on: https://gerrit.instructure.com/28953
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
QA-Review: Joel Hough <joel@instructure.com>
also fix with_each_shard
Change-Id: Ideb8371e3e36059aeca8ca1b756ca9e9188f1116
Reviewed-on: https://gerrit.instructure.com/29978
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
refs CNVS-9522
in rails3 ActiveRecord::Base.skip_callback is a real thing that doesn't
do what this does. because of load order, ours happens, but it would be
nice to leave the other available.
to simplify the switch, both suspend_callback and suspend_callbacks are
kept as renames, but suspend_callback should not be used, preferring
suspend_callbacks. suspend_callback will go away in the near future.
skip_callback is temporarily added back in as an alias to
suspend_callback to allow time for fixing a plugin that uses
skip_callback. it will be removed as soon as that plugin is updated.
Change-Id: Iaefd16dde3b6ce575780cb8f721dc826258eef4e
Reviewed-on: https://gerrit.instructure.com/29808
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
This was a beta api that didn't work out.
Test plan:
canvas should still work (sorry, this touches lots of stuff)
Change-Id: I31680b83f72f6d739ce74735ba40d7a760debb33
Reviewed-on: https://gerrit.instructure.com/29506
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
fixes cross shard user search by id for rails 3
prevents the where from inferring the user's home shard, cause this query
really needs to happen on the account's shard
Change-Id: I0a3539be638ece276b8fb33f87c75e8a33ab51ef
Reviewed-on: https://gerrit.instructure.com/29589
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Change-Id: I7e0e9db5d4d8f920ce63c4dfcac966783473c39a
Reviewed-on: https://gerrit.instructure.com/29716
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Change-Id: I0bc5b04d6210c90aa607e23714e7e78a2964e8ff
Reviewed-on: https://gerrit.instructure.com/29517
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Change-Id: I746004e5d6ab6ac0a4d7d557a799f878c0a84501
Reviewed-on: https://gerrit.instructure.com/29401
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
CNVS-10780
test plan
- create two email communication channels
- verify that the primary channel has default preferences
- verify that the other channel has all preferences set to never
- retired the primary channel
- ensure that the other channel now has default preferences set
Change-Id: I14de93894864dac5353c815235932680b8151b2c
Reviewed-on: https://gerrit.instructure.com/29378
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
it was the only external user of all_dates_visible_to, so making this change
allows all_dates_visible_to to be module private. additionally,
dates_hash_visible_to will ignore the default due date if all sections are
overridden, which is a more standard behavior.
closes CNVS-10538
test plan:
- basic regression test of the 'upcoming assignments' list on the user and
course dashboards for assignments with multiple due dates (check different
combinations of overriding all/some sections, and having dates in
and outside of the 'upcoming' window)
Change-Id: I13ca8a61d8813204edb88f1812ec51783d6a24ce
Reviewed-on: https://gerrit.instructure.com/28658
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Sutter <csutter@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Change-Id: I49ef9e0cc05fe233ae4b984d58cfb06f683363ca
Reviewed-on: https://gerrit.instructure.com/28770
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
Change-Id: I8d3ba6ddd3f6d9fd0a5dfba8bfab8a4419c8713c
Reviewed-on: https://gerrit.instructure.com/28628
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Change-Id: I3c119c315cb0224407d1ba3c1ccd26933445fb16
Reviewed-on: https://gerrit.instructure.com/28456
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
The method had a bug where if you passed a list
of user IDs (as opposed to User objects), it would
attempt to execute only on the current shard.
Fixes CNVS-10099
Test plan: specs should pass
Change-Id: I7a6faa20ef5156235af721b7e69264b47cd38a65
Reviewed-on: https://gerrit.instructure.com/27758
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Anthus Williams <awilliams@instructure.com>
Gives account admins the options to display
announcements to users that have a given role in
at least one course. This will enable us to, e.g.
write surveys intended for teachers and ensure
they will not be seen by K-12 students, etc.
Currently the granularity of this feature extends
only to the base enrollment types, (defined in
RoleOverride::ENROLLMENT_TYPES) not to the custom
roles that may have been defined in a given
account.
Fixes CNVS-8319
Test plan
- While logged in as an account admin or site
admin, browse to /accounts/N/settings#tab-announcements
and add a new announcement
- You should see the enrollment types delineated as
checkboxes
- Create an announcement defined for one role but
not another
- Log in as a user who has one of the defined roles
in at least one course to verify you are seeing the
announcement
- Log in as a user who has does not have any of
the defined roles in any of his enrolled courses
and verify that you do not see the announcement
- Verify it works for "Unenrolled users" (which is
not, in fact, a type of role in the same vein as
the rest) by logging in as a user who is not
enrolled in any courses
- Check "Account admin" option with a user who
does not have any role for which the announcement
is defined, but is an account admin (added under
the Admins section of /accounts/N/settings)
Change-Id: I7d141c7c38dc05ae72991de3a710043327d615f6
Reviewed-on: https://gerrit.instructure.com/27008
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Munda Frazier <munda@instructure.com>
fixes CNVS-10255
test plan:
- in a course with draft state enabled
- create an assignment, publish it, grade it
- it should show up for a student in 'recent feedback'
- unpublish it
- wait 15 minutes for the cache to expire
- it should no longer show up in 'recent feedback'
Change-Id: I074fb27edd0862827233167c17949b0fefd7cf85
Reviewed-on: https://gerrit.instructure.com/28059
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Sutter <csutter@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
fixes CNVS-10079
test plan:
- with draft state enabled
- as a teacher, create an assignment due the next day
- leave the assignment unpublished
- as a student, check the calendar
- the unpublished assignment should not be in the calendar
Change-Id: I679f593578a2fb287046f1905a8fa451762b9f46
Reviewed-on: https://gerrit.instructure.com/27741
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Cameron Sutter <csutter@instructure.com>
fixes CNVS-9931
test plan:
- with draft state enabled
- as a teacher, create an assignment due within the next week
(leave it unpublished)
- as a student, view the main home page and the course home page
- the assignment should not show up in the 'Coming Up' list on the right
Change-Id: Ifb1711199c8758063cc680bdd6e0390fe7a75ca2
Reviewed-on: https://gerrit.instructure.com/27501
Reviewed-by: Mike Nomitch <mnomitch@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Cameron Sutter <csutter@instructure.com>
in preparation for rails 3
Change-Id: I048e4f8db97dacf64616ad52ec075516b55f3c0f
Reviewed-on: https://gerrit.instructure.com/26966
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
fixes CNVS-9331
instead, as appropriate, use one of (or a combination of, if necessary):
* instance variable caching
* Rails.cache
* query caching (implicit)
also:
* remove the buggy cc.active_pseudonyms (didn't account for
sharding) in favor of cc.user.all_active_pseudonyms
* streamline assignments in the menu to not need to construct method
names
test-plan: N/A
Change-Id: Id0dec60464a283985e39493b90711b32cb5cca82
Reviewed-on: https://gerrit.instructure.com/26936
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
test plan:
- install the test_features plugin (since no real features exist yet)
- render and consult the feature flags documentation
- have a test environment with a root account,
sub-account, course in sub-account, and user
- Use the "list features" endpoint as a root account admin
(with no site admin privileges), on the root account context, and
confirm that hidden features do not show up
- Use the "list features" endpoint as a site admin user,
on the root account context, and confirm that hidden features
show up
- Use the "list features" endpoint on the site admin account
and confirm the hidden features show up
- Use the "set feature flag" endpoint on a hidden feature on site
admin and ensure the feature becomes visible in all root accounts
- Use the "set feature flag endpoint" on a hidden feature on a
single root account, and ensure the feature becomes visible to
that root account and not others
- Confirm that root_opt_in features appear "Off" by default
in root accounts, after being "Allowed" in code or site admin
- Confirm a feature flag that is set to "on" or "off" (vs. "allowed")
cannot be overridden in a lower context (and the API returns
locked=true for them)
- Confirm that setting locking_account_id requires admin rights
in the locking account
- Confirm that a feature flag with locking_account_id cannot be
changed without admin rights in the locking account (e.g.,
set a feature flag on a course, locked with the root account's id,
and make sure a teacher who is not an account admin can't change it)
- Confirm feature flags can be deleted with the "remove feature flag"
endpoint (and they are only deleted where they are defined, not
when called on an object that inherits a flag)
Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52
Reviewed-on: https://gerrit.instructure.com/25502
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Matt Goodwin <mattg@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
refs CNVS-9183
submit_homework is expensive, so just create the bare objects in specs
that do it a lot ... egregious example is 34sec -> 5.5sec, for all these
specs it's 546sec -> 449sec
Change-Id: I08e68dcfead83361601dd2b9cb00fcdf0400005e
Reviewed-on: https://gerrit.instructure.com/26389
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test plan:
* log in as user1
* go to user1's user settings
* click "Edit Settings"
* change "Enabled Theme" to "High Contrast"
* navigate to /styleguide
* verify that main header is darker (higher contrast)
* verify that the buttons at /styleguide#buttons have
** higher contrast
* log in as user2
* go to user2's user settings
* verify that the "Enabled Theme" is "Default"
* verify that the header is grayish (not as high contrast)
**********************************************************
* add a global css that changes something easily testable
** such as the header
* verify that the global css takes precedence
Change-Id: I7ce520be63ad639a77c603d7b3177df334750b15
Reviewed-on: https://gerrit.instructure.com/24787
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
It freezes the account, which then triggers memoize to pre-load all
memoized methods on the account, which of course are all very expensive
methods.
Also, it's pointless, because calling self.pseudonym.account a second
time will just return the same object without any more queries.
test plan: specs
Change-Id: I9c6ac1af7c769ebbc8bbc4e56a724a29ecad60f5
Reviewed-on: https://gerrit.instructure.com/26062
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Paul Hinze <paulh@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
refs CNVS-8958
@current_user.all_accounts was a fully instantiated collection;
paginating it did no real good besides spreading the results over
multiple requests while still loading the full collection for each page.
instead, use bookmarked with_each_shard pagination on the uninstantiated
scope. needs to be a method on User to parallel User#all_accounts in case a
plugin wants to augment User#all_accounts -- it should have somewhere to
hook to augment the paginatable version as well.
test-plan:
- /api/v1/accounts API still works when logged in
- the next page links change to bookmark page values, but otherwise
still give the same page contents
- the queries on the accounts table executed in the DB for the API call
have LIMIT clauses
Change-Id: I38a466d28b277fff4611b9d268c3d209bf6a1dfe
Reviewed-on: https://gerrit.instructure.com/25878
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
refs CNVS-8958
and fix User#all_accounts to just use it in the implementation
Change-Id: I0164f906ef083e2c38f744f63addd7d6217d8966
test-plan: existing specs
Reviewed-on: https://gerrit.instructure.com/25877
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
refs CNVS-8958
to parallel User#all_pseudonyms and make it clearer that it's embedding
the with_each_shard. temporarily alias back to User#accounts so we can
get past CI until plugins are updated with the new name.
Change-Id: I0698dfcbb1b418c1a66722d774df8821e31418b6
test-plan: existing specs
Reviewed-on: https://gerrit.instructure.com/25876
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
also force deleted_at to be utc
test plan
- delete a user
- the user should have deleted_at populated
- delete a quiz
- the quiz should have deleted_at populated
Change-Id: Ibf3442b832f648d754ac9959f053570bc8c06a19
Reviewed-on: https://gerrit.instructure.com/25585
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
refs CNVS-8282
test plan
- have scribd enabled
- upload a scribdable document to a course
- document should be rendered with scribd
- previously created documents should still render
Change-Id: Id8d7ea962c7bbe16b0f124e23447c66a48dd4100
Reviewed-on: https://gerrit.instructure.com/25566
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
This used to load courses one at a time on every page view
Change-Id: I70ecd3b3e85ee7638851babaf6ef807af177fbf0
Reviewed-on: https://gerrit.instructure.com/25581
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
deleting a user could cause thousands of update-cached-due-dates
jobs to be enqueued (one per assignment per enrollment; in the
referenced ticket, the test student had 13 enrollments and there
were 88 assignments, yielding 1,144 jobs, causing the request
to time out).
fix this by
(1) using a batch job to update all assignments in the course,
instead of a job per assignment
(2) when deleting a user with multiple enrollments in a course,
only run the update cached due date job once per course
test plan:
0. run in "production" configuration (i.e., in QA portal)
1. have a course with 10 sections and 100 assignments.
I suggest creating these in the console, e.g.
course = course.create! name: "CNVS-8068"
10.times { |x| course.course_sections.create! name: "section #{x}" }
100.times { |x| course.assignments.create! name: "assignment #{x}" }
2. enter student view mode in this course
3. reset the student view student
4. verify 1000 jobs were not created (and the request doesn't time out)
fixes CNVS-8068
Change-Id: If00dd3197b70df42b0f9ec18303b02594861f69f
Reviewed-on: https://gerrit.instructure.com/25160
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
fixes CNVS-8780
test plan:
1. create a user in one shard
2. try to self enroll in a course in another shard
3. it should work, and you should not get a page error
Change-Id: Id856686546499f90c4a77cd64d008b621cdc4158
Reviewed-on: https://gerrit.instructure.com/25257
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
use arel's where() instead. use of :conditions in has_many/has_one
remains, and a small handful of cases where rails2 sharding needs the
conditions in the find.
also, cleanup distinct_on() to only allow the :select/:option values it
works with directly; other finder options should be scoped in before the
distinct_on call.
fixes CNVS-8754
test-plan:
[1] communication messages API
- fetch /api/v1/comm_messages?user_id=self as a non-siteadmin; should
not error, should include the expected messages
[2] course roster
- load /courses/<id>/users
- invite a new student to the course; do not have that student accept
the invitation
- reload and open the web console; ENV.courses.pendingInvitationCount
should be 1
[4] list enrollments API endpoint
- full regression
[5] list conversations API endpoint
- fetch /api/v1/conversations; should not error, should include the
expected messages
[6] rubrics
- create a rubric with title "Example Rubric"
- create a second rubric with the same title; title should be changed
on save to "Example Rubric (1)"
- repeat to get "Example Rubric (2)"
Change-Id: I411676285348653044696d850efacf2e1a9e6585
Reviewed-on: https://gerrit.instructure.com/24996
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
rather than CANVAS_RAILS3 or Rails.version
this is to be consistent, and to reinforce that any "special" branches
are for rails 2.3 backwards compatibility while trying to target rails
3, rather than rails 3 "forwards compatibility".
Change-Id: I4494b65e3f71108a43d09032c1569c478646a828
Reviewed-on: https://gerrit.instructure.com/24998
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
fixes: CNVS-2197
Favorite courses between shards are broken due to the query performing an
EXISTS on the favorites table. This change fixes the query in that it gets
the favorite course ids from the users shard and converts them to a relative id
for the each shard the queyr runs on.
Test Case:
Setup:
- Create two courses, each on different shards.
(Course 1 on shard 1, Course2 on shard 2)
- Schedule a student from either shard 1 or shard 2 to both of
the created courses.
Note: A teacher should also be sufficient as long as they are associated to
both courses.
1. Log in as the student / teacher
2. Both courses should show under the
Courses menu.
3. Click the customize button in the courses menu.
4. Uncheck one of the courses.
5. Refresh the page and the courses menu should not show the course
that was unchecked.
6. Click the customize button in the courses menu.
7. Uncheck the other course so none of them are checked.
8. Refresh the page and the courses menu should
be reset back to normal. (Both courses showing and checked in customize) -
When all the courses are unchecked it should reset back to the default view.
9. Go through steps 3-5 again but with the opposite course.
10. Click the customize button in the courses menu.
11. Click the reset button.
12. Refresh the page and the courses menu should be reset back to
normal. (Both courses showing and checked in customize)
13. Add x number of courses and perform various customizations and the menu
should correctly reflect it even when courses span shards.
I also fixed a bug with the favorites. The favorites reset each time all the favorites
were unchecked. So unchecking all the favorites and then checking another one
reset the favorites to all of them. Here are steps to test that change:
1. Reset favorites
2. Uncheck all favorites
3. Check one favorite
4. Refresh the page and the only course visible should be the favorite that was
added in the previous step.
Change-Id: I8776696976b0974af42b7273333b39b88f388eb7
Reviewed-on: https://gerrit.instructure.com/24979
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Nick Cloward <ncloward@instructure.com>
now that we have SIGHUP, we were changing everything to it anyway,
so just let caching in-proc be the default
Change-Id: Id1b44722522ac9693b17695da7107c99a359d5ac
Reviewed-on: https://gerrit.instructure.com/25020
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
* use sort_by instead of sort where possible to avoid repeating yourself
* use new SortFirst/SortLast sentinels to avoid strange magical constants
* fix a few places of complicated logic for tiered sorting to just use
an array
Change-Id: I184ef0b4e31fa18294c9beb32770101d383bbea1
Reviewed-on: https://gerrit.instructure.com/24867
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-7199, CNVS-4414
abstract some ICU stuff out to Canvas::ICU, and add some missing
functionality in FFI-ICU
test plan:
* create a bunch of groups in the same category, named 1-10.
10 should sort after 9, not 1
* repeat for creating and publishing quizzes *with the same due date*.
go to the quiz index, and 10 should sort after 9, not 1
Change-Id: I323eb12dfb5bd23dbcbb3b543fa1b90a72f4341b
Reviewed-on: https://gerrit.instructure.com/24732
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs CNVS-7597
this was the only call site, and the implementation did a lot in ruby
that is better done in the database
test-plan:
- regression testing on /api/v1/courses/123/files
Change-Id: I120438c58f1c8de34503a0d14fc51d3853eb9385
Reviewed-on: https://gerrit.instructure.com/23943
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
1. make sure the returned stream item ids are relative to the user, not
the domain, since we need to look up the instances by those ids from
the user's shard later
2. make sure we actually handle shortened global ids, rather than
asploding
3. just cache stream items on the user's shard, not on every shard the
user visits. makes cache invalidation practical/possible
test plan:
1. set up canvas with redis and sharding
2. set up two additional shards (your user is in the initial/primary one)
3. enroll your user in a course in the second shard
4. as another user, do something that creates a stream item for the course
(e.g. create an announcement)
5. as the original user, confirm that:
1. you see the stream item on your shard's dashboard
2. you can dismiss the stream item
3. when you refresh the page, it is still dismissed
6. repeat step 4.
7. as the original user, confirm that:
1. you can see the stream item on the shard 3 dashboard
2. you can dismiss the stream item
3. when you refresh the page, it is still dismissed
8. as the original user, confirm that the items are dismissed from your
dashboard on all shards
Change-Id: I2c600685015640af36d9e33ac71e25cd536d7391
Reviewed-on: https://gerrit.instructure.com/24155
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
when looking up messageable users within a specific course or section,
we already know the relevant course's workflow_state in ruby-land, so we
don't need to join in the courses table just to check the workflow_state
and branch in the query.
test-plan:
regression tests around conversation recipient searching and user
search
Change-Id: I197276d68f4684539c9907941008bc46cc5fc44e
Reviewed-on: https://gerrit.instructure.com/24165
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
do a constant number of database queries instead of n^2 cache
lookups (which might miss and lead to several database queries
each)
test plan:
* reply to a small conversation and a large conversation
* it should work, and tags should continue to be calculated
correctly
Change-Id: Iddf488106338b65a97fc4b1335d8ab5c43ed8ae9
Reviewed-on: https://gerrit.instructure.com/23466
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
closes CNVS-7294
test plan:
* go to your dashboard, it should show your courses in the menu
* reload, should be the same
* clear the cache, and retry, should be the same
* repeat with a user enrolled in courses on multiple shards
Change-Id: I8e1450abb289e192642b3197781a208ab5a501ec
Reviewed-on: https://gerrit.instructure.com/22938
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
they were required prior to our new settings refactors. this way we don't
need to go set it in prod
test plan:
1. terms should be required when registering at /register
2. terms should be required when activing an account (via course
invitation email)
3. in the console, do Setting.set('terms_required', 'false')
4. terms should no longer be required on those pages
Change-Id: Idb13727839b847845cd4dacde4797e4e1571b42f
Reviewed-on: https://gerrit.instructure.com/22988
Reviewed-by: Mark Ericksen <marke@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-7134
test plan
- from the old conversations interface, ensure that the
conversations intro can be brought up from the help
menu
- from the old conversations interface, ensure that
clicking 'Try New Conversations' from the help menu redirects to
the new conversations interface
- ensure that navigating to /conversations redirects to the new
conversations interface after the user has switched to new
conversations
- from the new conversations interface, ensure that
clicking 'Switch Back to Old Conversations' from the help menu
redirects to the old conversations interface
- ensure that navigating to /conversations redirects to the old
conversations interface after the user has switched back to old
conversations
Change-Id: Ib8db233ebb56f915d0d183b704615de4bbe6539a
Reviewed-on: https://gerrit.instructure.com/23041
QA-Review: Cam Theriault <cam@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
fixes CNVS-7131
test plan:
* verify that the conversations API docs include subject
* verify that you can create a new conversation through
the API with a subject
* verify that you can create a new conversation through
the API with a subject to multiple recipients
* verify that conversations API responses include subjects
* open conversations beta interface
* verify that the conversation list includes subjects
* select a conversation
* verify that the subject is displayed above the messages
Change-Id: Ib4f32dc8348d08c10db42ddbe2022565de88dd9d
Reviewed-on: https://gerrit.instructure.com/22754
Reviewed-by: Joel Hough <joel@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
Product-Review: Braden Anderson <banderson@instructure.com>
fixes CNVS-6889
test plan:
1. log in to canvas
2. you should not have to agree to the terms
3. in a rails console, do
Setting.set 'terms_required', true
a = Account.default
a.settings[:terms_changed_at] = Time.now.utc
a.save!
4. reload the page
5. you should still not have to agree to the terms
6. log out and back in
7. you should be prompted to accept the terms
8. try to go to another url, e.g. /conversations
9. you should still be prompted to accept the terms
10. go ahead and agree to the terms
11. you should be able to use canvas as usual
12. log out and back in
13. you should still be able to use canvas as usual
Change-Id: Id9f0995f6da3aa3b73b226d0e0a2e339994502df
Reviewed-on: https://gerrit.instructure.com/22727
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
fixes CNVS-6280
refactors User#time_zone and Account#default_time_zone to return actual
time zone objects instead of strings.
Assignments to the fields accept both forms; reading the field prefers
to return a Rails friendly name, but the IANA name is easily accessible
from that object. Continue to use Rails names for the UI, but use
IANA names for the API.
test plan:
* in the UI, ensure that you can change timezones and it persists
correctly in the following locations:
* user profile as the user
* root account settings
* user page as an admin
* check the API responses for /api/v1/users/self/profile and
/api/v1/accounts/self; the time zone should be listed as an
IANA name (i.e. America/Denver, not Mountain Time)
* Update an account (PUT /api/v1/accounts/self) to change the
default time zone; ensure both friendly names and IANA names
are accepted on input, but on output the IANA name is returned
Change-Id: Ib976e7e1b2dde2639ff6fd478a59b38fdb0d07c0
Reviewed-on: https://gerrit.instructure.com/22563
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
when querying page views in the API, allow specifying start_time and
end_time. these are passed to the underlying event stream.
fixes CNVS-6995
test-plan:
- create some page views (logging a user in and out)
- request the page views through the API
- choose a page view in the middle and note its timestamp
- pass that timestamp as the start_time in the query string (ISO8601
formatted); only the newer portion of page views should be returned,
including the selected page view.
- pass that timestamp as the end_time in the query string (ISO8601
formatted); only the older portion of page views should be returned,
including the selected page view.
- try combining start_time and end_time where
* start_time < end_time (subset of page views returned)
* start_time = end_time (only the page view with matching timestamp
returned)
* start_time > end_time (no page views returned)
Change-Id: Id419d3b7c170b5997b0b5513f9d50d220feaeae4
Reviewed-on: https://gerrit.instructure.com/22487
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
The users/self/upcoming_events api was failing because it was
trying to serialize an appointment group as a calendar_event.
This doesn't make much sense because an appointment group could
be made of several disparate events spanning an arbitrary
amount of time. Also, do you want all potential appointments, or
just the ones that users have signed up for?
removing this feature until this can be thought through more.
fixes CNVS-6563
test plan:
- as a teacher, use scheduler to create an appointment group
for tomorrow.
- call the users/self/upcoming_events api as the teacher and
make sure it doesn't return an internal server error
(returning an empty array is ok).
Change-Id: Ib9384fc0d62929dd969912cf5fbaa6c426227771
Reviewed-on: https://gerrit.instructure.com/21873
QA-Review: Cam Theriault <cam@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joel Hough <joel@instructure.com>
Product-Review: Jon Willesen <jonw@instructure.com>
fixes CNVS-6576
Test plan:
* run the SubmissionsApiController#for_students action as a teacher
(it's part of gb2)
* make sure some/all of the submissions have attachments
* you should see a reasonable amount of queries (not hundreds or
thousands)
* make sure gradebook2 correctly displays student submission data
Change-Id: If301a70eb001f7876aa94e476b2c76dfa664ae05
Reviewed-on: https://gerrit.instructure.com/21790
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
refs CNVS-6202
test plan:
* run specs with a foreign key on user_acccount_associations(user_id)
(in a later commit, cause we're not ready to add it yet)
Change-Id: I30fc37da78232c1b18b834309f67c365a346b892
Reviewed-on: https://gerrit.instructure.com/21753
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-5821
test plan:
* make API requests to /api/v1/accounts/<id>/users?search_term=bob
* verify it returns users with names or ids matching the search term
Change-Id: Ica91ffce6f2a381445985b4b02231a380ce820d0
Reviewed-on: https://gerrit.instructure.com/21487
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
basically, don't pull in huge blobs and includes when unnecessary
test plan:
* regression test on modules and requirements getting met
Change-Id: I9b6ed7b067837df5f51df23d48f54641175106c4
Reviewed-on: https://gerrit.instructure.com/20580
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-5706
users are now able to toggle the discussion auto-mark
as read feature. this setting is user-level, and when
it is off, discussion entries will only be marked as
read when manually marked by the user.
manual marking is part of CNVS-5705.
test plan:
* create a discussion in a course;
* as user A, post an entry to the discussion;
* as user B, navigate to the discussions index page and
click the gear menu; check the "manually mark
posts as read" checkbox and save the setting;
* click into the discussion posted to by user A and
verify that user A's post is not automatically marked
as read;
* uncheck the "manually mark posts as read" checkbox
and save the setting;
* revisit user A's post and verify that is marked as
read without any input.
* repeat steps above twice: once with user B as a
teacher, once with user B as a student.
Change-Id: I2ff13705dfbee7d90e4e6c4003215d617fc0ef48
Reviewed-on: https://gerrit.instructure.com/20441
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
when a user explicitly logs out of one pseudonym session, invalidate all
the others
fixes CNVS-1923
test-plan:
- create a user in two different accounts
- log them in to both accounts
- click "log out" in one account
- should be logged out of both accounts
Change-Id: I79e70017d753c8201429901421e015f5d20e2000
Reviewed-on: https://gerrit.instructure.com/20096
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
fixes CNVS-620
test plan:
* create a course with at least two enrollees (A and B);
* as enrollee A, send a message to enrollee B;
* conclude the course, create a new course, and enroll
users A and B in it;
* as enrollee A, send a message to enrollee B and verify
that the message's tags update to include the new
course.
Change-Id: I36332c84a9602aee31b2e2ee1e73b12e87462e38
Reviewed-on: https://gerrit.instructure.com/20221
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Willesen <jonw@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-5552
some requests may need to make several messageable_user related calls
for the same user. using a new calculator object for each skips any
in-object caching we've done, resulting in excessive cache traffic.
instead, reuse the same calculator object for any calls for the same
user during a request.
removes the convenience class methods on MessageableUser::Calculator
since (1) they're no longer used, and (2) the user's
messageable_user_calculator should be used instead.
test-plan:
- general conversation regression
- have redis caching set up
- create a user with multiple courses all with a common letter in the
title
- create multiple sections for each of those courses
- in the recipients field search for that character
- check logs; should not have excessive
context_permissions/courses/X/users/Y cache lookups
Change-Id: Ib015c59e7c735fca8ec5ba1998f08dff609e29d2
Reviewed-on: https://gerrit.instructure.com/20126
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
extracted out of canvas-lms
refs CNVS-4713
test plan:
* actions that use a slave should still work (dashboard render)
* you should be able to switch envs and users in console
Change-Id: I07dda8057cf94383bc4579f1ef6b5a4b3ffc20b5
Reviewed-on: https://gerrit.instructure.com/19287
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Fixes #assignments_needing_submitting for the User model by expanding the range
of assignments to include assignments that have an override where the
due date is overridden and meets the date criteria.
test plan:
- as a teacher, create a new assignment with multiple due dates. Don't
select an "Everyone Else" section, but do have a due date for each
section that is within 1 week of now.
- as a student in one of the overridden sections, view your dashboard.
- the assignment should show up under the student's "todo" items on
the right side.
fixes CNVS-5088
Change-Id: Ie81beb32556006aff8707467660c67552e8b72c4
Reviewed-on: https://gerrit.instructure.com/19452
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
adds a new LTI extension, "content", that
defines the interaction for sending content from
a tool provider to the tool consumer. This extension
will replace the "embed_content" and '"select_link"
selection_directives, as well as adding allowing
am external tool to submit content for a homework
submission.
also starts sending intended_use, return_types, return_url
and file_extensions as part of the LTI launch with the new
extension.
test plan:
- make sure the "more" tab only shows up when there are valid tools
- install at least one valid tool
(make a homework_submission tool by taking the xml for
a resource_selection tool and replace "resource_selection"
with "homework_submission")
- click "more"
- make sure you can't submit the assignment when no
resource has been selected
- set an assignment that only allows file uploads
- try selecting a url from the tool
- make sure it errors out
- set an assignment that only allows file uploads
- limit the file types
- try selecting a file with a non-supported file extension
- make sure it errors out
- set an assignment that only allows file uploads
- try selecting an invalid file from the tool
- try submitting the homework
- make sure it errors out gracefully
- set an assignment that only allows file uploads
- try selecting a file from the tool
- make sure the submission works correctly
- set an assignment that only allows urls
- try selecting a file from the tool
- make sure it errors out
- set an assignment that only allows urls
- try selecting a url from the tool
- make sure the submission works correctly
Change-Id: I8df682bc73087681159110ab02f77f0e5a2b3911
Reviewed-on: https://gerrit.instructure.com/13419
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Adam Phillipps <adam@instructure.com>
Product-Review: Brad Humphrey <brad@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
fixes CNVS-1170
test-plan:
- be able to find messageable users and contexts from any shard,
regardless of the shard you're on
Change-Id: I5c5828a9c66eb3e6eb9f3e713f389723d514784c
Reviewed-on: https://gerrit.instructure.com/18146
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
closes CNVS-4705
* use the fake_arel gem to get a good portion of the way there
* override fake_arel's AR override even more to get proper behavior
of select and group merging
* add even more Rails 3 query methods to Scope (except, reorder,
pluck, uniq)
* fix some spots in our code that break with the new semantics
test plan:
* test all the things!
Change-Id: I4290d00db407f3250570df4e89c8c78283fe5f5f
Reviewed-on: https://gerrit.instructure.com/18427
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
adds a parameter to indicate the enrollment state for a course
in the lti launch parameters
test plan:
* create an external tool module item for a course
* check the "open in new tab" option
* click on the module item link
* inspect the source page elements and look for an "input"
tag with "custom_canvas_enrollment_state", that will either
show "active" or "inactive" based on the current user's
enrollment state
fixes #CNVS-4264
Change-Id: I2cff488ef178a87f5aacaadbeeb47338ca41b424
Reviewed-on: https://gerrit.instructure.com/18499
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Adam Phillipps <adam@instructure.com>
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>
Fixes an issue where if an assignment had an applied due date of `nil`,
User#upcoming_events would throw an exception when trying to sort a list
of events/assignments, because comparing nil against Time/TimeWithZone
objects made the sorting invalid ("Comparison of Array with Array
failed").
test plan:
- Make a course with a student. the student shouldn't be in the
default section for the course.
- As a teacher, create two assignments.
- For the first assignment, have a a section that does not have a due date
(blank due date when editing the assignment form). Make sure the
student is in this section that has no due date.
- For the second assignment, create as many overrides as you like,
ensuring that each override has a real due date.
- View the dashboard. The right side bar should load without you
getting any errors.
- View the course home page (/courses/:course_id). It should load
without any errors as well.
Change-Id: I0547ce16354ec1f735b5b16c1937853e245f790b
Reviewed-on: https://gerrit.instructure.com/18482
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Reviewed-by: Simon Williams <simon@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>
test plan:
- Make an assignment with multiple due dates, applying to different
sets of students. One section should have the assignment due within
a week, another due in at least 1 week + 1 day, and make a default
due date of the coure due within a week.
- The students who can see due dates within a week should have the
assignment under "Coming Up" with the correct information on the
right hand side of the dashboard when it loads.
- The student who has a due date > 1 week shouldn't see it in "Coming
Up" on the dashboard.
fixes CNVS-4433
Change-Id: I1819a2db0c00b2da216f2b5673667623423e0c1e
Reviewed-on: https://gerrit.instructure.com/18416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Simple "with_each_shard" fix for the
actual enrollment loading code.
I also pushed the data transformations down into
a presenter since there were so many
instance variables, and added some focused
specs around the presenter. (and updated
the view to reference all collections
from the presenter, memoizing to ensure
nothing gets transformed more than once)
Finally, to make the grade book summary work,
had to branch off of Jacob's fix for foreign
keys across shards and make use of
'relative_id_for' in the gradebooks_controller
fixes CNVS-2201
TEST PLAN:
1) login as a user who has enrollments
in 2 courses on different shards.
2) navigate to "/grades"
3) you should see all your courses, not just
the ones on your current shard.
Change-Id: I385bd94cce71bf2aee03b1ae7679157c08910924
Reviewed-on: https://gerrit.instructure.com/17667
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
fixes CNVS-3969
test-plan:
* create user A on shard 1
* create user B on shard 2
* create course C on shard 2 and enroll both A and B
* create a conversation between A and B
* have A open his inbox on shard 2 and filter by course C
* the conversation between A and B should show up
Change-Id: I0289ba8ecd44b50928ae35bfb9006c7e75fa774d
Reviewed-on: https://gerrit.instructure.com/17970
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jacob Fugal <jacob@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>
test plan:
1. go to /register
2. you should not be prompted to enter a birthdate in any of the flows
3. the forms should work
4. go to your (user) settings
5. you should not see your birthdate nor be able to enter one
6. the form should work
7. go to the self enrollment page for a course as a new user
8. you should not be prompted to enter a birthdate
9. the form should work
Change-Id: I9bf92d27e208696b2aed74b4a6396d434494679c
Reviewed-on: https://gerrit.instructure.com/18143
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
QA-Review: Cam Theriault <cam@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>
The batch update runs in a background job and updates a
Progress record while it runs. Based on the recently added
course controller's batch_update method.
fixes CNVS-2962
test plan:
- read and check the api documentation for the conversations
batch_update call
- create some conversations for a user using the GUI
- use the new api call to perform batch updates on that user's
conversations
- refresh the user's inbox and verify the conversations were
updated properly.
Change-Id: I185bb5402675b6f0475efed21a525c5d4d8a39cb
Reviewed-on: https://gerrit.instructure.com/17556
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
fixes CNVS-3606
Test plan:
* download some gradebook csv in a large class
* experience euphoria and surprise as your gradebook csv is quickly
delivered
Change-Id: I44e5fe14d73993d669eb6600072d6e2d125ad3cc
Reviewed-on: https://gerrit.instructure.com/17593
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
test plan
- create an assignment with no due date
- create a section override for the assignment with a due date
less than one week in the future
- as a student not in the overridden section, ensure that pages
that include the "Upcoming Assignment" list do not crash
Change-Id: I877fd8eabf31b68fb071903050ab3eb228050a70
Reviewed-on: https://gerrit.instructure.com/17520
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-1220
test plan
when checking for an assignment listed as upcoming, check:
- the "Coming Up" sidebar on the right of the user's or course's
"Recent Activity" page
- the "Upcoming Assignments" sidebar on the right of the user's
or course's Assignments page
- the "Upcoming Assignments" section on the main listing on the
user's or course's Assignments page
ensure assignments can be overridden to be upcoming
- create an assignment that is due more than one week from now
- as a student, ensure the assignment is not listed as upcoming
- create an override that applies to the student that makes the
assignment's due date less than one week from now
- As a student, ensure that the assignment is listed as upcoming
ensure assignments can be overridden to not be upcoming
- create an assignment that is due less than one week from now
- as a student, ensure the assignment is listed as upcoming
- create an override that applies to the student that makes the
assignment's due date more than one week from now
- As a student, ensure that the assignment is not listed as upcoming
Change-Id: Ia517d87f0a8ed48f6ce3ca466258e7ad8ebe650c
Reviewed-on: https://gerrit.instructure.com/17168
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Stanley Stuart <stanley@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
refs CNVS-1171
test plan:
* tags should show up and make sense when communicating with
someone in a different shard
Change-Id: I21da08d17740dafde766d368300d197897c3639b
Reviewed-on: https://gerrit.instructure.com/17082
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
fixes CNVS-2200
normalize ignores out of the users.preferences column into
its own table. makes it more performant, and shard safe
test plan:
* add a user as a teacher in courses on two different shards
* set up an assignment needing grading (i.e. have a student
submit an assignment that requires grading) in both courses
* the assignment should show up on the teacher's dashboard
regardless of which shard he's on
* ignore the assignment on your dashboard on one shard
* reload - it should stay gone
* it should also be gone on the other shard
* have another student submit to that assignment
* it should come back on both shards for the teacher
* ignore it, permanently this time
* have another student submit to that assignment
* it should still be gone on both shards
Change-Id: I6646410273c6be05d4b21b29b6ab76feb8e65d0f
Reviewed-on: https://gerrit.instructure.com/17295
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
fixes CNVS-1338
basically, just process associations for the current shard, unless
we're explicitly calling update_account_associations on just the user
(since all the other triggers will only affect associations within
the same shard)
test plan:
* enroll an existing site admin user from the default shard in to a
course on another shard
* the user should immediately show up in the course's account's user
list
* remove the user from the course
* the user should immediately disappear from the course's account's
user list
* note the associations a user has
(u.user_account_associations.with_each_shard)
* delete them all (u.user_account_associations.with_each_shard { |s|
s.delete_all })
* call u.update_account_associations
* make sure they all get recreated
Change-Id: I794363d1703fb2d46cd27b67b1216fedef4deaae
Reviewed-on: https://gerrit.instructure.com/17155
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
refs CNVS-1338
in preparation for calculating for multi-shard users
test plan:
* no visible change in behavior (in cases where the user doesn't
cross shards; this case will be defined and corrected in a
subsequent commit).
* things to regression test are that after adding a user to a course
in a sub account, they show up in the account; after removing them
from the course, they disappear from the account
Change-Id: Ie86d9dfa9978b42cb01503ace08a5fa6ea8638cc
Reviewed-on: https://gerrit.instructure.com/17141
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Clare Hetherington <clare@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-1338
test plan:
* run the migration on production-like data
* it should not fail
Change-Id: Ib8527f2cbee05d5e00941286f16c245091b1a2d9
Reviewed-on: https://gerrit.instructure.com/17117
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
refs #CNVS-1831
TEST PLAN:
1) no change in behavior, just a refactor
2) attempt to merge 2 users together
3) you should not suffer any surprise errors
during the user merge process
Change-Id: I8691b59e302dfda84dceeb890edafc54ade30c46
Reviewed-on: https://gerrit.instructure.com/16934
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
closes #CNVS-2464
test plan:
- turn self-enroll on for a course (course settings, more options)
- copy the secret URL
- turn self-enroll off
- go to the secret URL
- it should say enrollment is closed and not a 404 page
Change-Id: Ibd3f1c36f3c444dad48d4f492756d1db320475d8
Reviewed-on: https://gerrit.instructure.com/17226
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
fixes #CNVS-3432
stack traces were coming up in production with
the error "must be a root account".
granting the manage_logins permission on the
user model involved checking all user accounts
for subset permissions by loading up and then
examining all account users in every one of
a user's accounts, something that raises
an error in the account.rb model unless the accout
being examined is a root account. This
fix changes that permission check to only
examine root accounts, and also provides a
backup edge-case handler in
#has_subset_of_Account_permissions? which
just returns false if the account being examined
is not a root account.
TEST PLAN:
1) login as a local admin
2) go to the detail page for a user
within the context of an account, in particular
one where the user being examined is affiliated
with at least one non-root account:
example (https://wharton.instructure.com/accounts/81471/users/1189725)
3) you should not get any internal server errors,
and should be able to view the user's details.
Change-Id: I3a3995581bcc9bc7eb4074ea3f1ddeb66c598344
Reviewed-on: https://gerrit.instructure.com/17249
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
This commit fixes a regression from d30084, in which calls to
Api::V1::assignment_json were not being provided needed fields such as
'turnitin_settings' when accessed through the todos api. This caused the
instantiated ActiveRecord objects to throw an exception because the
field(s) had not been assigned.
test plan:
- Ensure you have a todo, e.g. an assignment that you haven't
submitted but is due in the future.
- Make an authenticated API request for todos
(e.g. /api/v1/users/self/todo ).
- The API response should be successful and include todo information.
The API response should not contain an error message, or have an
HTTP status indicating errors such as 500.
fixes CNVS-3362
Change-Id: I8af8f17590ac8e37fa2a545c9e49deadf6f3d2b6
Reviewed-on: https://gerrit.instructure.com/17176
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
When the Conversations/Inbox page is loaded, it will
recompute the actual unread message count for the user.
Testing Notes:
===============
When testing locally...
* Using the console, force the counts to be wrong: (First find the user by ID)
u = User.find(id)
u.update_attribute(:unread_conversations_count, 10)
* If off in positive direction, it will show the number of unread more clearly.
You can verify it on the Dashboard or other pages. If testing negative,
you need to have some conversations marked as unread and the
count will not include them.
* Visit the "Inbox" page and verify that the count is corrected. Now on the
Dashboard, it will be correct.
Change-Id: I0ccbb3489f4a296cc565fb453ae50c69637bfd60
Reviewed-on: https://gerrit.instructure.com/16770
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
Reviewed-by: Jon Willesen <jonw@instructure.com>
fixes #CNVS-2611
also fix broken account user permission check (an account user could view
all users in a course, regardless of permissions). simplify logic in
enrollment_visibility_level_for
test plan:
1. as a student, confirm you can message the whole course
2. under account permissions, revoke "Send messages to course members"
from students
3. as a student, confirm you can only message admins in the course
Change-Id: I29d73c68b8d93c54616a515c699818025b4bb839
Reviewed-on: https://gerrit.instructure.com/16581
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
refs #CNVS-2496
TEST PLAN:
1) login as a local admin
2) navigate to the user management page for a
site admin
3) try to add a new login for them
4) it should not work!
Change-Id: I66b81162baa2508431b0d106b37ac83b9d763dd3
Reviewed-on: https://gerrit.instructure.com/16620
QA-Review: Adam Phillipps <adam@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
refs #CNVS-2634
TEST PLAN:
1) start with 2 students on the same shard
2) add 2 courses, one on the same shard as the
students, one on a different shard.
3) the target student should be given an
active enrollment in the remote-shard course
4) the distracting student should be given a
completed enrollment on the local-shard course
WITH THE SAME LOCAL ID AS THE ACTIVE ENROLLMENT
FOR THE TARGET STUDENT
5) run '#courses_with_primary_enrollment' on
the target student AR object.
6) the remote-shard course should be present
in the returned courses array.
Change-Id: Icf892839e90ea0c5e7de69802e4979db9e9d2a23
Reviewed-on: https://gerrit.instructure.com/16635
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
when adding to the user_ids, use the same type of object as the caller
Change-Id: I96ac0cd95c4b3492a398620c562af360a92e1036
Reviewed-on: https://gerrit.instructure.com/16623
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
* wrap RoleOverride#permission_for with enabled_for? that also takes a
context of where the permission is being applied, and recalculates its
enabled-ness relative to that context; use that for checking account
admin and enrollment permissions
* refactor User#can_masquerade to properly check for descendant
permissions
test plan:
* create a custom role in site admin. give it permission to
manage permissions
* in script/console, find that override and set apply_to_self=false
* add a user to that role, and login as that user
* the user should not be able to change permissions in site admin
* the user should be able to change permissions in the default
account
* add another role in site admin. give it permission to manage
permissions
* in script/console, find the override and set apply_to_self=true,
apply_to_descendants=false
* add another user to that role, and login as that user
* the user should be able to change permissions in site admin
* the user should not be able to change permissions in the default
account
* the first user should not be able to masquerade as the second user
and vice versa
* an Account Admin should be able to masquerade as either user
* create a custom role in the default account, give it permission
to manage permissions, and add a user to that role
* the first user should be able to masquerade as the new user;
the second user should not be able to masquerade as the new user
* general regression tests on permissions and masquerading
Change-Id: I20a1183b7dfec419634a92cda498f245187060ef
Reviewed-on: https://gerrit.instructure.com/15896
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
dashboards don't show these, and existing ones can be a little crazy if
they have lots of submission comments
also change cache key so these get regenerated
test plan:
1. dashboards should work
2. stream item api should work
3. specs should pass
Change-Id: I245f4464189a507f0e1a8c9dc1c4c1e9fd4b7566
Reviewed-on: https://gerrit.instructure.com/16502
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
add support for self enrollment caps to limit the size of a particular
course. there is no UI for setting caps (yet)
test plan:
1. run specs
2. follow test plan for https://gerrit.instructure.com/15819
Change-Id: Ibf0a8f04f0c2efa820d0850cef26dfae20849246
Reviewed-on: https://gerrit.instructure.com/16021
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
fixes #CNVS-1119, potentially supersedes
https://gerrit.instructure.com/14501 with a little work.
simpler flow that is more consistent with FFT signup. whether you click
the "join course" button (popup) or go to the join url, the workflow is
the same:
1. if you are authenticated, you just click the enroll button.
2. if you are not authenticated, you can either:
1. enter your (canvas/ldap) credentials and submit to join the course.
2. register and join the course (single form). you will then be
dropped on the course dashboard in the pre_registered state just
like a /register signup (you have to follow the link in your email
to set a password).
note that if open registration is turned off, option 2.2 is not available.
other items of interest:
* fix CSRF vulnerabilities where you can enroll authenticated users in
open courses, or un-enroll them if you know their enrollment's UUID
* move to shorter course-id-less route (w/ join code)
* reuse UserController#create
* handy openAsDialog behavior and embedded view mode
* better json support in PseudonymSessionsController#create
* extract markdown helper from mt
* show "you need to confirm your email" popup when you land on the course
page the first time (already showed on dashboard)
test plan:
1. test the authenticated/unauthenticated scenarios above, for both the
popup and join pages
2. regression test of /registration forms
Change-Id: I0d8351695356d437bdbba72cb66c23ed268b0d1a
Reviewed-on: https://gerrit.instructure.com/15902
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
- make course/account/user associations not load deleted grading standards
- make course copy not copy deleted grading standards
- never show more than 100 grading standards on a course/account page
fixes #CNVS-2230
test plan:
- in a course, create a grading standard
- delete it
- copy the course
- the destination course should not have that grading standard
Change-Id: I0063b5ca704667b2863f1d571c86df82c2a5cb97
Reviewed-on: https://gerrit.instructure.com/16108
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
refs #CNVS-1292
Was unable to find any job-per-student
behavior (not to say that we won't ever discover
any), but I did find several instances of loading
full collections into memory
of student objects or objects
that would be instantiated in the same order of
magnitude as students for a course, and was able
to tweak many of those. There are undoubtably
more to find.
Change-Id: I044a1d92f90c830b4d1d07f0d4de17a718bcbe55
Reviewed-on: https://gerrit.instructure.com/16030
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
test plan:
* full regression test on dashboard stream items and activity
stream in the API
Change-Id: I7739fd7d7ea6350f6f7088b7736fd5d287e9384e
Reviewed-on: https://gerrit.instructure.com/15487
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ethan Vizitei <ethan@12spokes.com>
QA-Review: Clare Hetherington <clare@instructure.com>
expose the existing GroupsController#context_index action
to API clients.
test plan:
* create account-level and course-level groups;
* make API requests as a student and verify that:
* at the course level, all of the groups you belong
to are returned;
* course groups you do not belong to are excluded;
* at the account level, a 401 is returned.
* make API requests as a teacher and verify that:
* at the course level, all groups are returned;
* at the account level, a 401 is returned.
* make API requests as an account admin and verify that:
* at the course level, all groups are returned;
* at the account level, all groups are returned.
Change-Id: I27775def062d700c6f1c1fbae4fd83f9eb03378f
Reviewed-on: https://gerrit.instructure.com/15939
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joel Hough <joel@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
In gradebook1 we serialize all columns in User objects, which turns
out to be a bad thing in Ruby 1.9 because it is now UTF-8 aware and
fails for some bad UTF-8 characters in the 'collkey' sortable name
column. We just remove collkey from the serializable columns and
we're good.
Test Plan:
1. Check that international characters in the sortable name field
does not break the gradebook1 page.
2. Specifically, check the original page on beta that discovered
this bug (and the only one we know for certain reproduces the
bug):
https://mtest2.beta-19.instructure.com/courses/8361/gradebook
fixes #CNVS-1972
Change-Id: I3b949faaf4abc4ae0a025ff097ec566c69fa5276
Reviewed-on: https://gerrit.instructure.com/15905
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
test plan:
* create users (with a login in an account) on two shards, then merge
them together
* enable MFA (optionally) on the account in the shard that the user
did not end up on
* log in as the user
* on the profile settings page, the link should be there to
configure MFA
Change-Id: I95468243647e3fb8f90d23b2c686c221fee8ee00
Reviewed-on: https://gerrit.instructure.com/15791
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
two major pieces:
* use context_type/context_id instead of context_code for
three relations so that sharding extensions will
automatically work
* deserialize stream item data as actual AR objects instead
of OpenObject (for similar reasons)
test plan:
* run the predeploy migration, but not the postdeploy one
* view your dashboard on a shard other than your home shard;
it should be identical to your home shard
* view courses that you are enrolled in with the same id but on
different shards. the activity stream should have the correct
data for the course in that shard, for both courses (i.e.
no mixing of data from the two shards)
* do actions that generate new stream items, and verify the new
items appear correctly for the above two steps
* run the postdeploy migration, wait for the job to finish, then
repeat the test plan
Change-Id: I8d5fcadb8d971acf7388a12e9151a3e927751f44
Reviewed-on: https://gerrit.instructure.com/15462
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test-plan:
- create/find a scope of users with multiple users with distinct
sortable names
- that_scope.order_by_sortable_name should still return them in
expected lexicographical order
- that_scope.order_by_sortable_name(:direction => :descending) should
return them in reverse lexicographical order
Change-Id: If3c3153e2817c8520bee8fcb9920a5fa1c8a60db
Reviewed-on: https://gerrit.instructure.com/15496
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan
* existing specs should all pass
* when including teacher enrollments from course conditions should keep enrollments.type
Change-Id: Ic99fc40069b4d5ab003ed43cd1b7c9f34454a43f
Reviewed-on: https://gerrit.instructure.com/15097
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
the new dashboard design categorizes recent activity into buckets that can be
expanded/collapsed, and inidividual messages can be dismissed. the categories
are announcements, conversations, discussions and assignments. this redesign
applies to the homepage dashboard, the group home page, and the course homepage
when "recent activity dashboard" is selected as the course home page type.o
the motiviation is that the dashboard should capture and present in one place
important information happening in all the user's courses or groups, and allow
for jumping into this information to see more details:
- announcements/discussions should show on the dashboard when they are created,
or when there are root replies to recent announcements
- conversations should show on the dashboard when there is new activity
- assignments should show on the dashboard when they are created, or when
changes are made at least a couple hours after being created
the presence of a dashboard item means there is activity for that item that may
be of interest to the user. additionally, the dashboard items will show
read/unread state (excluding assignments) for items which the user has not yet
viewed.
additionally, global messages such as course inivitations, account level
announcements, and new user messages have been restyled, but will keep their
place above the recent activity widget on the dashboard.
test plan:
- visit many exising user's dashboards and make sure they are functional in the
new style.
- visit canvas as a brand new user (no enrollments), a new user enrolled in
a new course and make sure the dashboard is restyled and the messaging makes
sense.
- make an account level announcement and make sure it shows up on user's
dashboards.
- create all different types of conversations: single, group, bulk private,
from submission comment, add user to convo, etc. and make sure the
appropriate dashboard items appear and make sense
- create discussions and announcements, reply to them at the root level and at
the sub entry level (sub entries will not make new dashboard items), test
from both a read and unread user's perspective, making sure dashboard items are
correct. (note that read/unread state will not be correct for existing items
before this code is applied, but should be correct for future items moving
forward)
- dismiss dashboard items and account announcements, make sure they stay
dismissed.
- test creating assignments, waiting > 2 hours, and updating due dates or other
assignment details. make sure items appear. note that unread state will not
exist for assignment notifications.
closes#10783
refs #11038
refs #11039
Change-Id: I276a8cb1fae4c8a46425d0a368455e15a0c470c5
Reviewed-on: https://gerrit.instructure.com/14540
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* run the specs
Change-Id: I3ecbebfa226b243c7a39d9ead0621c95583b0f84
Reviewed-on: https://gerrit.instructure.com/15119
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* create a pseudonym with an SIS id for a user on an account in a
different shard
* GET /api/v1/users/:user_id/profile for that user against the
account's domain (easiest to just use self)
* sis_login_id should be populated
Change-Id: Idd95b949c4180abc366071a110636d348aa24806
Reviewed-on: https://gerrit.instructure.com/14875
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
also change all_pseudonyms and accounts to use the new
HasManyAssociation#with_each_shard hawtness
test plan:
* enroll the same user in courses in multiple shards
* favorites don't work yet; be sure to reset them before
continuing
* courses from all shards should show up in your menu
* courses from all shards should show up in your all courses
page
* when enrolled as a student in a course not on the user's shard,
permissions should be correct (particularly, you should be able
to participate as a student - turn in assignments)
* enroll the user in groups from multiple shards
* all groups should show up in home menu
Change-Id: I84fffa39ebf3dee093ecff145670a29296da29a1
Reviewed-on: https://gerrit.instructure.com/14722
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Fixes#10793
Test plan:
1. Go to the gradebook and verify the gradebook version you are on.
2. Go to an assignment and load up the speedgrader.
3. Click the 'Gradebook' link at the top of the page.
4. You should be on the same version of the gradebook as you were
originally. Repeat steps 1-3 after switching to the other gradebook.
Previously, you were always taken to gradebook 1.
Other notes:
* Adds a 'gradebook_url_for' helper that accepts a user, context, and
assignment and constructs a URL based on the user's preference
Change-Id: I596202d448c61046efae1e13ab8c9e87c3f7768b
Reviewed-on: https://gerrit.instructure.com/14666
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
...in the CountReport to only users with a pseudonym that's been
accessed in the last 30 days. fixes#11381
Change-Id: Ic4c10b1bd49bc9f10e5d4ef20a7ea2bd78ab27b9
Reviewed-on: https://gerrit.instructure.com/14780
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
we're doing work and consuming storage keeping track of reminder
information that nobody is consuming.
should we decide to implement assignment reminders in the future,
reverting this commit would be an excellent start; then a
delayed_job that periodically called remind! on each result of
AssignmentReminder.needs_sending would get us most of the
way there.
Change-Id: I2b110cab79d53229b30c9fef64aac646b719a700
Reviewed-on: https://gerrit.instructure.com/14569
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* don't use set_shard_override, just set shard= directly
* when creating follows, run the transaction, the search, and
the create all on the same shard
* when searching for upvotes, root on the user, not the
collection item
Change-Id: I5ae3f29e5f48f92c02d3a0c0e04765956d8eb892
Reviewed-on: https://gerrit.instructure.com/14648
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
instead of relying on clone creating the object on the
currently active shard
test plan:
* same as previous cross-shard user merge test plan
Change-Id: I710bce60456ec5bcb11eb8d5fe56aa074e22be89
Reviewed-on: https://gerrit.instructure.com/14685
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Adds a new back-end store for page_views, using a Cassandra cluster. All
the current page view queries are supported, many using denormalized
views on the data.
test plan:
first, canvas instances that are currently using AR page views
should function as before.
by Setting.set('enable_page_views', 'cassandra') and restarting, you will
switch to cassandra page views. a script to migrate the AR page views to
Cassandra is coming. all page view functionality should work as before.
note that the format of the pagination headers in the
/api/v1/users/X/page_views endpoint has changed.
Change-Id: I2d1feb4d83b06a0c852e49508e85e8dce87507b4
Reviewed-on: https://gerrit.instructure.com/14258
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* merge a user in one shard into a user in another shard
* email addresses should come over (try pairs of users with
different combinations of duplicate e-mail addresses and
workflow states)
* being an admin should come over
* enrollments and pseudonyms also should come over, but aren't
visible in the UI yet
* user_services (twitter, facebook, linkedin, etc. on the profile)
should come over
* conversations and perma-observerness does *not* work yet
* three users, all from different shards, together, and confirm
the above again (especially being an admin, since that's what's
visible in the UI)
Change-Id: I2b2cac62a18663e22faf72ebaae8123f703146c6
Reviewed-on: https://gerrit.instructure.com/14182
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
also, make the implementations of those and user_(is|has_been)_student
consistent, and fix a bad cache key.
test-plan:
- everything but the cache key is just a refactor
- create and then delete a student enrollment in a course so that
user_is_student? and user_has_been_student? should be different
- enable caching
- call user_is_student?; should be false
- call user_has_been_student?; should be true
Change-Id: Ia9458605273741ef3971d8701fe3cff56453f9b4
Reviewed-on: https://gerrit.instructure.com/14580
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
refs #11187
I removed memoize before, since the thing being returned is an
array rather than a named scope once we restrict by section,
and thus would not return updated results on a single User
instance - but I noticed the _total_count functions are all
memoized and can't be expected to update either; also, we
probably don't expect these counts to change within a single
request.
also, move tests for User#assignments_needing_grading into
their own specs that actually test summing over multiple
assignments
test plan:
* no visible behavior change (other than possible speedup)
* specs should pass
Change-Id: I76c9d91b75ebcdf4dd48b356171f1bd13b011520
Reviewed-on: https://gerrit.instructure.com/14345
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
test plan:
* on a user's own shard, go to their user page (/users/self
is probably easiest)
* create a login
* refresh
* update the login
* refresh
* delete the login
* refresh
* repeat for the same user, from a different shard
* for this case, all logins for the user from any shard should
display
Change-Id: I7d60a6a70e0f5166db05abcafd498bbe754cffb7
Reviewed-on: https://gerrit.instructure.com/14262
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
we use this after all. fixes#11187
test plan:
* have a course with 9 or more assignments needing submissions
* as a student, make a submission to each (so 9 need grading)
* as a teacher, try to view the front Canvas page; you should
not see a page error
Change-Id: If865eed8fd69b85154dd1a38d2637fd14f43f984
Reviewed-on: https://gerrit.instructure.com/14287
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
gravatar has started proxying fallback images, which breaks things if the
host is localhost or something not publicly accessible. set fallback host
to canvas.instructure.com in dev and selenium environments (w/ a
mechanism to override it).
test plan:
1. run canvas locally
2. gravatar fallback images should work again
3. run canvas in beta/production
4. gravatar fallback images should still work, and the url should have the
current hostname in the proxy path (e.g.
https://i1.wp.com/foobar.instructure.com/images/.. )
Change-Id: Idfd2129e0d78026b2bcfd57e8c7399e0b29f8a3a
Reviewed-on: https://gerrit.instructure.com/14245
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan:
* Create a course with multiple sections
* Enroll students in both sections, and submit assignments. Keep
track of how many submissions were made in each section.
* Create a TA in one section, with limited privileges, and log in
as that TA.
* Check the to-do list on the right panel, and make sure it only
includes submissions from the TA's section.
* Check the TODO items API, and make sure the needs_grading_count
figure only includes submissions from the TA's section.
* Check the needs_grading_count in the Assignments API;
it should include only submissions in the TA's section
* Check the needs_grading_count in the Courses API;
it should sum all the submissions to all the assignments
in the TA's section of the course
Change-Id: I5f1f47321bb909abc24deabdfa47b8301dc83d8f
Reviewed-on: https://gerrit.instructure.com/14026
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
crocodoc does not allow viewing sessions to be created when the user
name sent to crocodoc has a comma, we need to scrub it out.
test-plan:
* as a student, submit a crocodocable file as a submission
* change the teacher short name(display name) to have a comma
* make annotations on the student submission as the teacher
* view teacher annotations as the student
* during both viewing sessions, the teacher's name on the annotiations
should not have a comma
Change-Id: Iebfc7f8137ea8e49fef139fdfec932bdb464d85d
Reviewed-on: https://gerrit.instructure.com/14208
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
This also refactors the UserList constructor to better support passing this
information in when a user is being created through an invitation.
Testing Steps:
=========
* In a course, go the Settings > Users tab.
* Under "Add Course Users", select a type (ex: "Students") and
give the user information.
* Ex: "Student Test" <studenttest@example.com>
* After adding the user, verify in the console that the user has
the correct initial_enrollment_type. (As far as I know, this
information isn't displayed anywhere)
* Sample console script:
* u = User.last
* u.initial_enrollment_type #=> "student"
Can verify that this works for the following supported types
"student", "teacher", "ta", "observer".
Anything else (like Designers) doesn't get stored.
Change-Id: I5d900c421a04e95b5b92e21cd57e7694d1e98958
Reviewed-on: https://gerrit.instructure.com/14110
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan:
* add a user from one shard as an admin in an account in another
shard
* that account should show up in the user's home menu, and their
all accounts page
Change-Id: Ib92b1a7f9283f6444d4a59108dc783f583b245bc
Reviewed-on: https://gerrit.instructure.com/14077
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* edit course settings, there should not be an error
* copy a course, there should not be an error
Change-Id: I733bef83b69d9c513be801d3e4b25422bcd10ebd
Reviewed-on: https://gerrit.instructure.com/13832
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
fixes#10036
This commit removes the ability to sort files and folders by
dragging and replaces it with a default of alphabetizing every
item.
Test plan:
*Folder
1. Go the to files page http://localhost:3000/dashboard/files
2. Create a folder named "d_folder" then add a folder named "a_folder"
3. Ensure "a_folder" is before "d_folder"
*Files
1. Go the to files page http://localhost:3000/dashboard/files
2. Upload a file named "d_file.txt" then add a file named
"a_file.txt" (must have characters in the file"
3. Ensure "a_file.txt" is before "d_file.txt"
Change-Id: I3776ff996e338f8aa6fc3858b59e1460b8b1cdf0
Reviewed-on: https://gerrit.instructure.com/13554
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
notifications were happening on monday because
TimeWithZone.advance(:days => x) does nothing. move them to saturday for
real and also spread them over the Eastern-time day instead of lumping
them all at 8pm (admittedly by timezone, but that's only 4 hours for the
continental US, which is the current majority of users).
add an indicator to the notification preference page to show a rough
time block in which they can expect their weekly messages to be sent.
fixes#8296
test-plan:
setup:
- create two accounts the same id but on different shards (shard ids
should not differ by a multiple of four)
- in each a account, create a user with a communication channel; call
them Alice and Bob.
- create a third account on the same shard as Bob's account but with a
different id (account ids should not differ by a multiple of four)
- in this account create two users with a communication channel each;
call them Charles and David.
- for each of the four users, assign a notification to deliver to the
user's communication channel weekly
- on Friday, trigger the associated notifications for each user
- on Sunday, trigger David's notification again
expectations:
- each user should receive the messages on saturday (Eastern-time),
not monday
- Alice's and Bob's emails should arrive in different "quarter days"
- Bob's and Charle's emails should arrive in different "quarter days"
- Charles' email and David's first email should arrive in the same
"quarter day" but in different hours
- David's emails should come a week apart, but in the same hour both
times
UI:
- go to the notifications preference page
- should see note at bottom indicating two hour block during which
their weekly notifications will be sent
- actual send time of weekly notifications should fall within that
block
Change-Id: I97bb75762ef8c03fae99ad5499b441f7c026d2c8
Reviewed-on: https://gerrit.instructure.com/13963
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
implement background message sending in the inbox. when sending any
message, the form now unlocks right away and a progress bar appears
at the top. you can potentially have several messages sending at once,
each with its own progress bar. determinate progress bars (i.e. for
bulk private messages) will still be on the page if you reload (assuming
they haven't finished sending).
also implement client-side form validations so that users are prompted to
put in recipients and a message
progress bar should be aria compliant. refs #9237
test plan:
1. send a new message to a single recipient
2. there should be an indeterminate progress bar as it sends, and the ui
should be unlocked
3. send a new group message
4. see step 2.
5. send a bulk private message
6. there should be a determinate progress bar as it sends, and it should
move with a relatively consistent velocity. the ui should be unlocked
7. send a message on an existing conversation
8. see step 2.
9. repeat steps 1-8 with attachments
10. try sending messages without a body or recipients. you should get red
error boxes
Change-Id: I1e4641505c3e4c42f840b292d739c78cb1c2baff
Reviewed-on: https://gerrit.instructure.com/13617
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Adds support for optionally viewing documents with Crocodoc.
closes#9865
Test plan:
* configure the crocodoc plugin
* add an assignment that allows file uploads
* make a submission for that assignment with a pdf or doc or ppt
- on the 'submission details' page, opening a preview of the
assignment should display it in crocodoc
- speedgrader should display the submission in crocodoc too
* make a submission with odt or rtf
- the submission should be displayed with scribd or google docs
* if you disable the crocodoc plugin, submissions could continue being
previewed in google docs or scribd
Change-Id: I7dd2547f8e2d907c98ebe894a7f1ee9d58f1e030
Reviewed-on: https://gerrit.instructure.com/13668
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
added migration to oauth requests to allow longer
return urls
test plan user settings:
1. login as a user
2. click on the user name in the top right
3. click Edit Settings button
4. try to enter a string larger than 255 characters
in full name, display name, and sortable name
5. should stop text entry at 255 characters
test plan user groups:
1. login as a teacher
2. go into a course
3. click 'People' on left nav
4. click 'View User Groups' on right nav
5. click 'Make a New Set of Groups' on right nav
6. try to enter a group name longer than 255 characters
7. should stop text at 255 characters
Change-Id: I9be845a611357eed6512aba73a491a3d16af0e03
Reviewed-on: https://gerrit.instructure.com/13772
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
fixes gh#211
test plan:
* use the /api/v1/courses/{courseId}/recent_students endpoint with
a mysql backend
Change-Id: Id19944044cf6cce1e11a847b60c7d7294dd33c89
Reviewed-on: https://gerrit.instructure.com/13628
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
added uber_scope fu to override association :select/:order. slight
refactor of order_by_sortable_name (which incidentally makes it so custom
:select's get respected rather than getting all columns)
test plan:
1. go to a course with more than 20 concluded enrollments
2. go the prior enrollments page
3. it should be paginated
4. spot check other places that order_by_sortable_name (e.g. user_notes)
5. they should work
Change-Id: I3176876383a03d38950b2159cbb73931017d1cc1
Reviewed-on: https://gerrit.instructure.com/13167
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
closes#10051
eliminate some n+1 queries in the users api by being consistent about
preloading necessary associations. also refactor the user api docs so that
they follow the new @object/@returns model
test plan:
- make sure user api docs look good (and user parts of course api docs)
- there should be no noticiable changes to api behavior
- in dev, tail the logs, make some queries with lots of users, and make sure
they are reasonable.
Change-Id: I4a3b0b94bbce4c62cdbfc83941b79b25773ba904
Reviewed-on: https://gerrit.instructure.com/13022
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
refs #9889, refs #8592
This commit removes support for twitter and linkedin profile pictures,
as they are too small.
Test plan:
* rake db:migrate
* go view some profile pages
* the profile pics should not be ghetto-scaled
Change-Id: Ibea84420351cabbb496b1a8e5860d6e5834bb8ac
Reviewed-on: https://gerrit.instructure.com/13030
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This will bypass a lot of extra rails requests on things like discusison
topic pages.
refs #9679
test plan: load a discussion topic with lots of user avatars of
different types, veryify they still display correctly.
Change-Id: I29829806da30410c6b938ff3bcf54329a58698c4
Reviewed-on: https://gerrit.instructure.com/13050
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
* calendar events in the .ics feed
* searching for users in an account
* user's recent stream items
test plan: verify that these functions still work, both with and without
a slave db configured
Change-Id: Ia596d388642cc9df16e471472406d447a5eb1cf0
Reviewed-on: https://gerrit.instructure.com/13025
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
test plan: as a site admin, or another user who has no account
association but can view an account, visit an account that you aren't linked to.
you shouldn't see a page error.
Change-Id: Ib9544d188ff0e5cb3deb4753967fd69ab485b859
Reviewed-on: https://gerrit.instructure.com/13019
Reviewed-by: Bryan Madsen <bryan@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
fixes#9993; fixes#10034
we were caching the user's common account chain, but this was occasionally
caching all of the accounts loaded associations, which wasn't unmarshaling
properly.
the new strategy is to cache the global asset paths that should be used for
different contexts.
test plan:
- no visual changes in sub-account branding
- shouldn't generate any caching errors (these were intermittent and we never
had solid steps to reproduce)
Change-Id: I37cc58a609ed7f90d967d6ebde74e849c754c0e8
Reviewed-on: https://gerrit.instructure.com/13017
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9451
rack's request.scheme doesn't take x-forwarded-proto into account, so it
was returning http. Using request.protocol correctly handles ssl
termination, it just means we have to chop off the "://" part of the
protocol.
test plan: In an environment using ssl behind a load balancer, load the
avatar for a user that doesn't have one. verify that the gravatar
request redirects back to canvas using https, not http.
Change-Id: Ifb5f42e91379cfe591d29e07cd2ccf1f9d2b19fa
Reviewed-on: https://gerrit.instructure.com/12865
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan:
* enable optional MFA, and check the following:
* normal log in should not be affected
* you can enroll in MFA from your profile page
* you can re-enroll in MFA from your profile page
* you can disable MFA from your profile page
* MFA can be reset by an admin on your user page
* when enrolled, you are asked for verification code after
username/password when logging in
* you can't access any other part of the site directly until
until entering your verification code
* enable required MFA, and check the following
* when not enrolled in MFA, and you log in, you are forced to
enroll
* you cannot disable MFA from your profile page
* you can re-enroll in MFA from your profile page
* an admin (other than himself) can reset MFA from the user page
* for enrolling in MFA
* use Google Authenticator and scan the QR code; you should have
30-seconds or so of extra leeway to enter your code
* having no SMS communication channels on your profile, the
enrollment page should just have a form to add a new phone
* having one or more SMS communication channels on your profile,
the enrollment page should list them, or allow you to create
a new one (and switch back)
* having more than one SMS communication channel on your profile,
the enrollment page should remember which one you have selected
after you click "send"
* an unconfirmed SMS channel should go to confirmed when it's used
to enroll in MFA
* you should not be able to go directly to /login/otp to enroll
if you used "Remember me" token to log in
* MFA login flow
* if configured with SMS, it should send you an SMS after you
put in your username/password; you should have about 5 minutes
of leeway to put it in
* if you don't check "remember computer" checkbox, you should have
to enter a verification code each time you log in
* if you do check it, you shouldn't have to enter your code
anymore (for three days). it also shouldn't SMS you a
verification code each time you log in
* setting MFA to required for admins should make it required for
admins, optional for other users
* with MFA enabled, directly go to /login/otp after entering
username/password but before entering a verification code; it
should send you back to the main login page
* if you enrolled via SMS, you should not be able to remove that
SMS from your profile
* there should not be a reset MFA link on a user page if they
haven't enrolled
* test a login or required enrollment sequence with CAS and/or SAML
Change-Id: I692de7405bf7ca023183e717930ee940ccf0d5e6
Reviewed-on: https://gerrit.instructure.com/12700
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
store whether the new user is a teacher/student/observer (if specified)
test plan:
1. sign up as a teacher/student/observer
2. it should work
3. the user record should have the correct initial_enrollment_type
Change-Id: I6200d677f2da946b05d6f90c89617b3476ed390b
Reviewed-on: https://gerrit.instructure.com/12873
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#9829
users without any enrollments weren't included in
User.messageable_users, but messaging yourself should always be allowed.
Test plan:
* log in as a user without any enrollments
- Go to your inbox. You should be able to message yourself by
searching for your name.
OR
- Go to your profile page on an account with profiles enabled. You
should be able to see your profile.
Change-Id: If5182d807fe2f3150999d442d30202c22dffa4d1
Reviewed-on: https://gerrit.instructure.com/12819
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
allow teachers/admins to link observers to students in courses that have
not yet been published
test plan:
1. create a course, but don't publish it
2. add a student
3. add an observer
4. confirm that you can link the observer to the student
Change-Id: I48871d569533afc355db39ff52849a2c4b8b6a49
Reviewed-on: https://gerrit.instructure.com/12739
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
fixes#9669, fixes#9713
Test plan:
* for #9669
- Go to the users tab of the settings page for a course
- Add a unexisting user to the course
- Add an observer to the course (if there isn't one)
- Open the link student dialog (still on user settings page)
- Search for the previously added student - the student should show up
* for #9713
- In a course with some student groups defined, go again to the users tab
- Open the edit sections dialog for a student
- click the button on the right of the input, no student groups should show up
- search for a group, none should show up
Change-Id: Iacc6aa9be109983fd53520bc547a62cb9482be89
Reviewed-on: https://gerrit.instructure.com/12702
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
change the the list of recently logged in users to be loaded
asynchronously and paginated via the api.
test plan:
- navigate to /courses/:course_id/statistics;
- click on the 'Students' tab;
- verify that the most recent students have
loaded;
- in a course with > 25 users who have logged in, and some of
whom have multiple pseudonyms, view the same page
- verify that while scrolling, more students are loaded automatically
in until all the students in the course are present in the list.
Change-Id: I10ea92e0a286ce117ec0e957a91c8c347b89e751
Reviewed-on: https://gerrit.instructure.com/8404
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
users have a new profile page that displays a
custom bio, links, and contact methods as well as
how the viewing user knows them.
this profile can be a part of any page and is
displayed on the user in a course pages as well.
profiles are found at /about/:user_id
Change-Id: I3339144135d67415af9068d18776b691320c1938
Reviewed-on: https://gerrit.instructure.com/12298
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Implementing the re-designed Notification Preferences page.
Testing plan:
=========
* Verify that expected preferences can be set.
* Verify that it supports accessibility (screen readers) for blind users
* Verify that mobile users (iPad at least) can smoothly interact.
Change-Id: I2b98f2477932d800d2ec3de580e47a95f827616b
Reviewed-on: https://gerrit.instructure.com/12356
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
check for presence of two new arrays in messagable_users because the method
they come from is cached for 1 day and so may not include them immediately.
test plan:
- you'll only see this if you have sent a conversation message in the 24
hours before applying 7e3c30b1 and have caching enabled
- make sure sending a conversation message works.
Change-Id: I4670893e077efc5c5734b01338364175384deb80
Reviewed-on: https://gerrit.instructure.com/12408
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
allow sub accounts to include their own global scripts and stylesheets. if
global includes are enabled on the root account, root account administrators
will have an option to enable them for immediate child accounts. those child
accounts can then choose to enable them for their sub-accounts, and so on down
the chain.
these includes are added to the page in order from highest to lowest account,
so sub-accounts are able to override styles added by their parents.
the logic for which styles to display on which pages is as follows:
- on account pages, include all styles in the chain from this account up to the
root account. this ensures that you can always see styles for account
X without any sub-account overrides on account X's page
- on course/group pages, include all styles in the chain from the account which
contains that course/group up to the root
- on the dashboard, calendar, user pages, and other pages that don't fall into
one of the above categories, we find the lowest account that contains all of
the current user's active classes + groups, and include styles from that
account up to the root
test plan:
- in a root account, create two sub-accounts, create courses in each of them,
and create 3 users, one enrolled only in the first course, one only in the
second course, and one enrolled in both courses.
- enable global includes on the root account (no sub-accounts yet) add files,
and make sure all three students see them.
- now enable sub-account includes, and add include files to each sub-account
- make sure both users in course 1 see include for sub-account 1
- make sure user 1 sees include for sub-account 1 on her dashboard, but user
3 does not.
Change-Id: I3d07d4bced39593f3084d5eac6ea3137666e319b
Reviewed-on: https://gerrit.instructure.com/12248
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
this moves the user bio to a new user_profile table. We previously had
a UserProfile model that was a regular ruby class, but now it is using
ActiveRecord
Change-Id: I8848ef9b5f7e2a7bbb5c12df8044efe26388ae78
Reviewed-on: https://gerrit.instructure.com/12178
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@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>
adds (root) account-level setting for (default) user file quotas. defaults
to 50 MB.
test plan:
1. on a root account, change the default user quota to something other
than 50 MB (e.g. 1 MB)
2. as a user in that account:
1. go to /users/self/files/quota . you should see the new quota
2. attempt to upload files. once you have hit/exceeded the quota, you
should not be able to upload additional files
3. as a user in multiple (root) accounts:
1. go to /users/self/files/quota . your quota should be the sum of the
root account user quotas
2. attempt to upload files. once you have hit/exceeded the quota, you
should not be able to upload additional files
note that the previous behavior does not change in that one file can exceed
your quota. e.g. if your quota is 1 MB, you can upload a 2 MB file. only
then will you be prevented from uploading additional files
Change-Id: If7f5903fb54eb2b62d80a2b4ee8adfcc48a63683
Reviewed-on: https://gerrit.instructure.com/12005
Reviewed-by: Joe Tanner <joe@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#8673
test plan:
- set up a course with students and observers
- link an observer to a student
- as a student, go to Inbox and click the address book icon
- verify that the only Observers that show up are those that
are linked to you
Change-Id: I2d9dfac1717c43b4327b48ef43efcffba34b30b1
Reviewed-on: https://gerrit.instructure.com/11971
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
fixes#9309
test plan:
* using the api, add a user as an account admin and pass the
notify=0 param. verify that no email is sent to that user;
* make another account admin api call, but omit the notify=0
param; verify that an email is still sent.
Change-Id: I450c08196d1acafae7cb5bec40a2e0e479e11341
Reviewed-on: https://gerrit.instructure.com/12008
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
fixes#9250
This isn't realistic on such a large table where many users have so many
rows, and when page views are moved to another data store that'll make
it even more difficult.
test plan: merge two users together. verify that the merge works, but
page views from the old user won't be moved to the new user.
Change-Id: I0d5cb73acaebc9ed38a16bd0952a64f6b5284f5a
Reviewed-on: https://gerrit.instructure.com/11948
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9209, #9216, #9217, #9227
visual changes:
* restore bootstrap form styles
* change "course code" to "join code"
* made dialog buttons consistent with rest of app
* fix observer submit button wording
* remove verbiage around minimum age (before validation)
* fix link to home page (logo)
behavioral change:
* only enforce min age for signups without a join code. once they fail
validation, display an error and hide the form
test plan:
* go through signup flows, ensure visual stuff above is correct
* ensure users with a course code can sign up with any age
* ensure users without a course code must be >= 13
Change-Id: I3d02a6f1a768ab054c825db30fb73a81f4eb5e59
Reviewed-on: https://gerrit.instructure.com/11939
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9156
Normally the instances are all deleted when the StreamItem is deleted,
but error conditions can leave orphaned instances around, which was
causing dashboard errors.
test plan: generate some stream items for a user, then manually delete
a relevant stream_items row from the database. Make sure the user can
still see the dashboard and query the activity stream from the api.
Change-Id: Iec4d19efa66a08ee0dc895125084b2e4879e12ab
Reviewed-on: https://gerrit.instructure.com/11800
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan: follow a user and a group, make sure that makes you
auto-follow all the existing collections. add a new collection and
verify you're now following that new collection.
this only applies to public un-deleted collections, or all un-deleted
collections if you're a member of the group.
Change-Id: I163f26661d8537f059955cf34edb48cbeafa24b6
Reviewed-on: https://gerrit.instructure.com/11381
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Create upvotes in the upvoting user's shard, so we can query for them,
and make the upvote_count and post_count cached counts update properly
cross-shard.
Remove a foreign key constraint that was preventing users on other
shards from posting items to a collection.
Create stream_item_instances on the user's shard, and make sure to query
them from there.
Further work should be done to optimize :include so that we can
efficient pull in the stream items for the instances.
test plan: as a user on one shard, interact with a collection on another
shard -- posting to it, upvoting/downvoting, cloning items from that and
other shards. verify you don't get errors, missing data, or incorrect
counts.
Change-Id: I91aeebd404cd20663a533b2f38c08ec90c65868e
Reviewed-on: https://gerrit.instructure.com/11228
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
the first time a user queries their own collections, or a member of a group
queries the group's collections, we create a default private collection for
them and return it, so there is always a colleciton to add to.
test plan:
- as a user who has never used collections before
- go somewhere that shows your collections (query through api for now,
eventually go to your profile page).
- you should have a collection named after you
- do the same as a member of a community
Change-Id: I6f75cf8971c6e2a0e990ce221d4cb149a8a8254e
Reviewed-on: https://gerrit.instructure.com/11275
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
1. sign up as a teacher
2. sign up as a student with a course code
1. confirm that you are auto-logged in as soon as you submit valid info
in the form
3. sign up as a student without a course code
4. sign up as an observer
1. confirm that you are auto-enrolled in the child's courses
5. test the log in form
Change-Id: I581de48095e85ca869b9ded101fe143ffadb9c9a
Reviewed-on: https://gerrit.instructure.com/11111
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
A user can currently follow a Collection, and another User.
Right now following doesn't do anything -- a subsequent commit will add
stream item support for followed Collections.
Also don't scope collection endpoints with /users/X or /groups/Y etc,
except for the index/create actions
test plan: use the api to follow and unfollow users and collections.
verify that you can follow something on a different shard, and it'll
still get returned correctly.
Change-Id: I9fd3f179885327e49f4d220784509de0ea23c0a7
Reviewed-on: https://gerrit.instructure.com/11057
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
this adds show/create/edit/delete api actions for groups. currently create
only allows creating community groups. the changes to these controller
functions should be backwards compatible with course and student groups.
anyone should be able to create a community (for now), but only moderators or
account admins are allowed to edit/delete them.
test plan:
- test the four api actions from the command line
- make sure managing course and student groups still works (there should be no
visible changes here)
Change-Id: I9cac73ab434b0ba464ecfe399ab42174eff9b48a
Reviewed-on: https://gerrit.instructure.com/11148
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
- fix active tab issue in sidebar on group settings page
- stats table is now composed of followers, collections, collection
items
Change-Id: I88df0001b1cdffcb7f92e7b365b3ae00880f72e8
now joins the users/courses tables to ensure that order clauses
work and uses SQL from User::ENROLLMENT_CONDITIONS to guarantee
that students are not given their enrollments in unpublished
courses.
test plan:
* create a user with at least one enrollment;
* make a call to /api/v1/:user_id/enrollments?state[]=:workflow_state
and verify that enrollment(s) are returned as expected;
* generally test enrollments#index to ensure that nothing is
broken.
Change-Id: Id09850537d793089fcf6bfae2fabd214154ceefa
Reviewed-on: https://gerrit.instructure.com/10933
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
also fixed user merging so that observer enrollments get merged when
merging observed users
test plan:
1. test observer enrollment creation/updating
1. enroll a student in some courses
2. create another user
3. add that user as an observer of the student (via console)
4. confirm that the user gets enrolled as an observer in the student's
courses
5. enroll the student in another course
6. confirm that the observer is also enrolled
7. conclude the student's enrollment in a course
8. confirm that the observer's enrollment is also concluded
2. test observer enrollment consolidation (via user merge)
1. observe two users in a course
2. merge the users
3. confirm that you just have one observer enrollment after the merge
3. test observer enrollment creation (via user merge)
1. enroll user 1 in course A
2. enroll user 2 in course B
3. observe user 1
4. merge the users (either direction)
5. confirm that you are now observing the user in both courses
Change-Id: Ic5ab29157ab8fc8dc9e7b32cafebbb1290bd4f6b
Reviewed-on: https://gerrit.instructure.com/10811
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
These were hard coded to always return 21 items, same as the dashboard
screens in the web UI. They're now fully pagniated, though the per_page
default in this case is 21, to match the old behavior.
test plan: make an api call to users/self/activity_stream and
courses/X/activity_stream, and verify the pagniation. this touches the
code for the activity stream in the ui in a refactor, but shouldn't have
any visible changes.
Change-Id: I8da63eb4e03bb616d66d0af27efa30ef786dd3dd
Reviewed-on: https://gerrit.instructure.com/10678
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Joel Hough