Commit Graph

4 Commits

Author SHA1 Message Date
James Williams 36a815448b update relative_id_for to switchman style
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>
2014-02-04 14:14:20 +00:00
Nick Cloward 1b1ce45f3c add option for course grade change (log auditing)
fixes: CNVS-8996

Added a grade change audit UI for searching grade change events.  This allows the
user to search based off of the grader, student, course id, and assignment id.
In addition to each parameter a date range can be selected.

Currently assignment and course can only be searched if the ID is known.  This
is because there is no way to query for courses based on a name with the api.

Note: The submission after_save :grade_change_audit needed to be after the
simply_versioned call because the grade change audit uses that to grab the
previous grade.  This was a bug in the grade change audit log api.  This
fixes that issue also.

Test Case:
  - Create a course with an assignment and student.
  - Grade the assignment for the student.
  - Change the grade for the student a few times.
  - Open the admin tools. Select the Logging tab and then pick the grade change
    activity option in the drop down.
  - Search for the grader.  The results from the grade changes should show
    accordingly.
  - Search for the student.  The results from the grade changes should show
    accordingly.
  - Search for the course id.  The results from the grade changes should show
    accordingly.
  - Search for the assignment id.  The results from the grade changes should
    show accordingly.
  - Perform each search type again, testing the date range capabilities.
  - Make sure you cannot search with an invalid date range, grader, and student.
  - Enter an invalid course id,  no results should be returned.
  - Enter an invalid assignment id,  no results should be returned.

Change-Id: Ie5a4d34dbb60627374035071c68ec4d404e80135
Reviewed-on: https://gerrit.instructure.com/26868
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Nick Cloward <ncloward@instructure.com>
Product-Review: Nick Cloward <ncloward@instructure.com>
QA-Review: Nick Cloward <ncloward@instructure.com>
Tested-by: Nick Cloward <ncloward@instructure.com>
2014-01-09 23:50:57 +00:00
Nick Cloward e983251c9d add 'links' container to jsonapi-style API objects
fixes: CNVS-9757

Change the authentication log api to return relationships (foreign keys) based
on jsonapi with a links element.  This also changes the page_view object to
also move the relationship (foreign keys) to the links element in the json.

Requires underscore.js 1.5.2.  See g/27313

Test Case:
  Authentication Logs:
    - Create some authentication logs if you don't have any by logging in and out.
    - Test the authentication logs api to make sure its returning in the correct
      format and data.
    - Open the admin tools
    - Search for authentication logs in the logging tab.
    - Search by date.
    - Ensure the page is not broken.

  Page Views:
    - Create page view data.
    - Test the page view api to make sure its returning in the correct
      format and data.
    - Test the analytics page views.
    - Test the user profile page views.
    - Account stats for page views.
    - Generating the CSV's/page views for page views.

  Make sure the API documentation reflects the changes.

Change-Id: Ic8aa9e5da4df58e2816fb348accac62b17ec20d5
Reviewed-on: https://gerrit.instructure.com/26907
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Nick Cloward <ncloward@instructure.com>
2013-12-17 23:50:27 +00:00
Jacob Fugal 59737086e7 Auditors::Authentication
fixes CNVS-390

stores and allows querying by user/account/pseudonym of login/logout
events.

test-plan:
  [setup]
    - set up an 'auditors' keyspace in cassandra and run migrations
    - have shardX and shardY on one database server, and shardZ on a
      different database server
    - have accountW and accountX on shardX
    - have accountY and accountZ on shardY and shardZ, respectively
    - have userA on shardX with pseudonymAW in accountW and pseudonymAX in
      accountX (cross-account, single-shard user)
    - have userB on shardY with pseudonymBY in accountY and pseudonymBX in
      accountX (cross-shard user)
    - have userC on shardZ with pseudonymCZ in accountZ and pseudonymCX in
      accountX (cross-db-server user)
    - log in and out of each pseudonym above multiple times

  [index isolation]
    - /api/v1/audit/authentication/pseudonyms/<pseudonymAX> should
      include logins and logouts from pseudonymAX only
    - /api/v1/audit/authentication/accounts/<accountX> should include
      logins and logouts from pseudonymAX, pseudonymBX, and pseudonymCX
      but not pseudonymAW
    - /api/v1/audit/authentication/users/<userA> should include logins
      and logouts from both pseudonymAW and pseudonymAX but not
      pseudonymBX or pseudonymCX

  [permission isolation]
    (in each of these, either :view_statistics or :manage_user_logins on
    an account qualifies as "having permission")
    - /api/v1/audit/authentication/pseudonyms/<pseudonymAX> should be
      unauthorized if the current user doesn't have permission on
      accountX
    - /api/v1/audit/authentication/accounts/<accountX> should be
      unauthorized if the current user doesn't have permission on
      accountX
    - /api/v1/audit/authentication/users/<userA> should be unauthorized
      if the current user doesn't have permission on either of accountW
      or accountX
    - /api/v1/audit/authentication/users/<userA> should include logins
      and logouts from accountW but not from accountX if the current
      user has permission on accountW but not on accountX

  [sharding]
    - /api/v1/audit/authentication/users/<userB> should include logins
      and logouts from both pseudonymBY and pseudonymBX
    - /api/v1/audit/authentication/users/<userB> should not include
      duplicate logins and logouts from either pseudonymBY and
      pseudonymBX (potential for bug due to both pseudonyms' shards
      being on the same database server)
    - /api/v1/audit/authentication/users/<userC> should include logins
      and logouts from both pseudonymCZ and pseudonymCX

Change-Id: I74b1573b346935f733fe5b07919d2d450cf07592
Reviewed-on: https://gerrit.instructure.com/21829
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>
2013-07-12 16:10:33 +00:00