This data point is difficult to get with the new page views
infrastructure, and isn't displayed anywhere anyway.
fixes CNVS-6731
test plan:
* with cassandra page views enabled, open a rails console and run
Reporting::CountsReport.process
* once that completes, go to /accounts/X/statistics and verify that the
stats have been updated (there is a generated timestamp at the top)
Change-Id: I7f1144cd6dab9b68478a79e3f7f82bc6d8feb0b3
Reviewed-on: https://gerrit.instructure.com/22046
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@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>
...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>
test plan:
* run CountsReport with a slave environment that's not writeable
Change-Id: Ie99db198a42a505401bde711c674349763b79bad
Reviewed-on: https://gerrit.instructure.com/10721
Tested-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This will get added back in once page views are moved out of the
database.
test plan: visit an account statistics page, the two lines of page view
counts in last week/month will be gone. The CountsReport periodic job
should now not do the page view rollup queries.
Change-Id: Icb947a88ff6644d600a31593ff07050f964b8580
Reviewed-on: https://gerrit.instructure.com/10640
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
test plan:
* run Reporting::CountsReport.process; it should work
* add a slave db configuration as a child of the current
environment to database.yml; re-run the CountsReport
Change-Id: Iba08d6697cf0e864ecbc3a2829fcd7a134267bec
Reviewed-on: https://gerrit.instructure.com/10100
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
basically for detailed reports, have a row per account, instead of
stuffing everything into one massive hash with every account
test plan:
* ensure that the account statistics page still works
* ensure that the statistics update when the delayed job runs
Change-Id: I2d4c9ff5a86c8df6d82097aa4f0203a0f55ddb2d
Reviewed-on: https://gerrit.instructure.com/9565
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
just make Account#root_account return self if it is a root account
test plan:
* run existing specs
Change-Id: Iff3f621bb722e0f5e90659c4b711d48d8d3c510f
Reviewed-on: https://gerrit.instructure.com/7700
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
in preparation for having Account#root_account return self if it is a root account
also remove some unused named scopes
test plan:
* run specs
Change-Id: I8c78c45f0d2f6002021bc2bba594de8bcbaa086b
Reviewed-on: https://gerrit.instructure.com/7698
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
This was already a small issue if the job queue was on a different
database driver than the main database, and it'll become more important
as more AR connections are introduced.
Change-Id: I204becadd32bb935df096e8c937a04bb6962f0b2
Reviewed-on: https://gerrit.instructure.com/4601
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
also limit the job to one attempt
Change-Id: I65bad8ae6e7aa79e4916d4f5f03ef67d2dc683de
Reviewed-on: https://gerrit.instructure.com/3980
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Brian Palmer