gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
#
2017-04-28 03:34:17 +08:00
# Copyright (C) 2013 - present Instructure, Inc.
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
#
# @API Gradebook History
# @beta
#
# API for accessing the versioned history of student submissions along with their
# grade changes, organized by the date of the submission.
#
#
2014-02-12 07:21:09 +08:00
# @model Grader
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# {
2014-02-12 07:21:09 +08:00
# "id": "Grader",
# "description": "",
# "properties": {
# "id": {
# "description": "the user_id of the user who graded the contained submissions",
# "example": 27,
# "type": "integer"
# },
# "name": {
# "description": "the name of the user who graded the contained submissions",
# "example": "Some User",
# "type": "string"
# },
# "assignments": {
# "description": "the assignment groups for all submissions in this response that were graded by this user. The details are not nested inside here, but the fact that an assignment is present here means that the grader did grade submissions for this assignment on the contextual date. You can use the id of a grader and of an assignment to make another API call to find all submissions for a grader/assignment combination on a given date.",
2016-01-19 02:22:23 +08:00
# "example": [1,2,3],
2014-02-12 07:21:09 +08:00
# "type": "array",
# "items": {"type": "integer"}
# }
# }
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# }
#
2014-02-12 07:21:09 +08:00
# @model Day
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# {
2014-02-12 07:21:09 +08:00
# "id": "Day",
# "description": "",
# "properties": {
# "date": {
# "description": "the date represented by this entry",
# "example": "1986-08-09",
# "type": "datetime"
# },
# "graders": {
# "description": "an array of the graders who were responsible for the submissions in this response. the submissions are grouped according to the person who graded them and the assignment they were submitted for.",
# "example": "[]",
# "type": "array",
# "type": "integer"
# }
# }
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# }
#
2014-02-12 07:21:09 +08:00
# @model SubmissionVersion
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# {
2014-02-12 07:21:09 +08:00
# "id": "SubmissionVersion",
# "description": "A SubmissionVersion object contains all the fields that a Submission object does, plus additional fields prefixed with current_* new_* and previous_* described below.",
# "properties": {
# "assignment_id": {
# "description": "the id of the assignment this submissions is for",
# "example": 22604,
# "type": "integer"
# },
# "assignment_name": {
# "description": "the name of the assignment this submission is for",
# "example": "some assignment",
# "type": "string"
# },
# "body": {
# "description": "the body text of the submission",
# "example": "text from the submission",
# "type": "string"
# },
# "current_grade": {
# "description": "the most up to date grade for the current version of this submission",
# "example": "100",
# "type": "string"
# },
# "current_graded_at": {
# "description": "the latest time stamp for the grading of this submission",
# "example": "2013-01-31T18:16:31Z",
# "type": "datetime"
# },
# "current_grader": {
# "description": "the name of the most recent grader for this submission",
# "example": "Grader Name",
# "type": "string"
# },
# "grade_matches_current_submission": {
# "description": "boolean indicating whether the grade is equal to the current submission grade",
# "example": true,
# "type": "boolean"
# },
# "graded_at": {
# "description": "time stamp for the grading of this version of the submission",
# "example": "2013-01-31T18:16:31Z",
# "type": "datetime"
# },
# "grader": {
# "description": "the name of the user who graded this version of the submission",
# "example": "Grader Name",
# "type": "string"
# },
# "grader_id": {
# "description": "the user id of the user who graded this version of the submission",
# "example": 67379,
# "type": "integer"
# },
# "id": {
# "description": "the id of the submission of which this is a version",
# "example": 11607,
# "type": "integer"
# },
# "new_grade": {
# "description": "the updated grade provided in this version of the submission",
# "example": "100",
# "type": "string"
# },
# "new_graded_at": {
# "description": "the timestamp for the grading of this version of the submission (alias for graded_at)",
# "example": "2013-01-31T18:16:31Z",
# "type": "datetime"
# },
# "new_grader": {
# "description": "alias for 'grader'",
# "example": "Grader Name",
# "type": "string"
# },
# "previous_grade": {
# "description": "the grade for the submission version immediately preceding this one",
# "example": "90",
# "type": "string"
# },
# "previous_graded_at": {
# "description": "the timestamp for the grading of the submission version immediately preceding this one",
# "example": "2013-01-29T12:12:12Z",
# "type": "datetime"
# },
# "previous_grader": {
# "description": "the name of the grader who graded the version of this submission immediately preceding this one",
# "example": "Graded on submission",
# "type": "string"
# },
# "score": {
# "description": "the score for this version of the submission",
# "example": 100,
# "type": "integer"
# },
# "user_name": {
# "description": "the name of the student who created this submission",
# "example": "student@example.com",
# "type": "string"
# },
# "submission_type": {
# "description": "the type of submission",
# "example": "online",
# "type": "string"
# },
# "url": {
# "description": "the url of the submission, if there is one",
# "type": "string"
# },
# "user_id": {
# "description": "the user ID of the student who created this submission",
# "example": 67376,
# "type": "integer"
# },
# "workflow_state": {
# "description": "the state of the submission at this version",
# "example": "unsubmitted",
# "type": "string"
# }
# }
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# }
2014-02-12 07:21:09 +08:00
# @model SubmissionHistory
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# {
2014-02-12 07:21:09 +08:00
# "id": "SubmissionHistory",
# "description": "",
# "properties": {
# "submission_id": {
# "description": "the id of the submission",
# "example": 4,
# "type": "integer"
# },
# "versions": {
# "description": "an array of all the versions of this submission",
# "type": "array",
2016-01-19 02:22:23 +08:00
# "items": {"$ref": "SubmissionVersion"}
2014-02-12 07:21:09 +08:00
# }
# }
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# }
#
2014-02-12 07:21:09 +08:00
class GradebookHistoryApiController < ApplicationController
2017-02-09 01:08:10 +08:00
before_action :require_context
before_action :require_manage_grades
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
include Api :: V1 :: GradebookHistory
# @API Days in gradebook history for this course
# Returns a map of dates to grader/assignment groups
#
2014-08-06 23:29:54 +08:00
# @argument course_id [Required, Integer]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The id of the contextual course for this API call
#
# @returns [Day]
def days
2013-04-18 01:40:52 +08:00
days_hash = days_json ( @context , api_context ( api_v1_gradebook_history_url ( @context ) ) )
2013-08-23 06:22:14 +08:00
render :json = > days_hash
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
end
# @API Details for a given date in gradebook history for this course
# Returns the graders who worked on this day, along with the assignments they worked on.
# More details can be obtained by selecting a grader and assignment and calling the
# 'submissions' api endpoint for a given date.
#
2014-08-06 23:29:54 +08:00
# @argument course_id [Required, Integer]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The id of the contextual course for this API call
#
2014-08-06 23:29:54 +08:00
# @argument date [Required, String]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The date for which you would like to see detailed information
#
# @returns [Grader]
def day_details
2013-04-18 01:40:52 +08:00
date = Date . strptime ( params [ :date ] , '%Y-%m-%d' ) . in_time_zone
path = api_v1_gradebook_history_for_day_url ( @context , params [ :date ] )
day_hash = json_for_date ( date , @context , api_context ( path ) )
2013-08-23 06:22:14 +08:00
render :json = > day_hash
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
end
# @API Lists submissions
# Gives a nested list of submission versions
#
2014-08-06 23:29:54 +08:00
# @argument course_id [Required, Integer]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The id of the contextual course for this API call
#
2014-08-06 23:29:54 +08:00
# @argument date [Required, String]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The date for which you would like to see submissions
#
2014-08-06 23:29:54 +08:00
# @argument grader_id [Required, Integer]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The ID of the grader for which you want to see submissions
#
2014-08-06 23:29:54 +08:00
# @argument assignment_id [Required, Integer]
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
# The ID of the assignment for which you want to see submissions
#
# @returns [SubmissionHistory]
def submissions
2013-04-18 01:40:52 +08:00
date = Date . strptime ( params [ :date ] , '%Y-%m-%d' ) . in_time_zone
path = api_v1_gradebook_history_submissions_url ( @context , params [ :date ] , params [ :grader_id ] , params [ :assignment_id ] )
submissions_hash = submissions_for ( @context , api_context ( path ) , date , params [ :grader_id ] , params [ :assignment_id ] )
2013-08-23 06:22:14 +08:00
render :json = > submissions_hash
2013-04-18 01:40:52 +08:00
end
# @API List uncollated submission versions
#
# Gives a paginated, uncollated list of submission versions for all matching
# submissions in the context. This SubmissionVersion objects will not include
# the +new_grade+ or +previous_grade+ keys, only the +grade+; same for
# +graded_at+ and +grader+.
#
2014-08-06 23:29:54 +08:00
# @argument course_id [Required, Integer]
2013-04-18 01:40:52 +08:00
# The id of the contextual course for this API call
#
2014-08-06 23:29:54 +08:00
# @argument assignment_id [Integer]
2013-04-18 01:40:52 +08:00
# The ID of the assignment for which you want to see submissions. If
# absent, versions of submissions from any assignment in the course are
# included.
#
2014-08-06 23:29:54 +08:00
# @argument user_id [Integer]
2013-04-18 01:40:52 +08:00
# The ID of the user for which you want to see submissions. If absent,
# versions of submissions from any user in the course are included.
#
2014-08-06 23:29:54 +08:00
# @argument ascending [Boolean]
2013-04-18 01:40:52 +08:00
# Returns submission versions in ascending date order (oldest first). If
# absent, returns submission versions in descending date order (newest
# first).
#
# @returns [SubmissionVersion]
def feed
student = api_find ( User , params [ :user_id ] ) if params [ :user_id ]
assignment = Assignment . find ( params [ :assignment_id ] ) if params [ :assignment_id ]
# construct scope of interesting submission versions using index table
indexed_versions = SubmissionVersion .
where ( :context_type = > 'Course' , :context_id = > @context ) .
order ( params [ :ascending ] ? :version_id : 'version_id DESC' )
indexed_versions = indexed_versions . where ( :assignment_id = > assignment ) if assignment
indexed_versions = indexed_versions . where ( :user_id = > student ) if student
# paginate the indexed scope and then convert to actual Version records
2017-03-04 05:12:35 +08:00
path = api_v1_gradebook_history_feed_url ( @context , params . permit ( :course_id , :assignment_id , :user_id , :ascending , :format ) )
2013-04-18 01:40:52 +08:00
indexed_versions = Api . paginate ( indexed_versions , self , path )
2015-12-19 05:47:46 +08:00
ActiveRecord :: Associations :: Preloader . new . preload ( indexed_versions , :version )
2015-11-18 07:36:08 +08:00
versions = indexed_versions . map ( & :version ) . compact
2013-04-18 01:40:52 +08:00
2013-04-30 07:20:52 +08:00
render :json = > versions_json ( @context , versions , api_context ( nil ) , :assignment = > assignment , :student = > student )
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
end
private
2013-04-18 01:40:52 +08:00
def require_manage_grades
authorized_action ( @context , @current_user , :manage_grades )
end
gradebook history api
fixes #CNVS-2802
This provides a reimplementation of
the functionality in 'lib/submission_list.rb'.
That lib file has been used to produce
a grade book history page, but it loads
the entire history of the course at once,
which is untenable. This take all the same data,
and provides it through a paginated
API endpoint. Using this API, a rich front
end will be possible to create in order to replace
the current large grade book history page,
one that makes API calls to reveal data further d
own the tree as it is requested. This is an
unusual API endpoint in that it does not present
data as it is in the database, there is a series
of transformations that the submission data is
put through to arrive at a versioned history
where each node contains within itself some
contextual knowledge of the flow of the
submission progress (each version knows
what the grade of the version before it was,
and what the grade is today, for example).
TEST PLAN:
This is a new API endpoint and does not
yet get used by any front end code yet.
It can be played with by performing some
valid API queries against the following paths:
/courses/:course_id/gradebook_history/days
/courses/:course_id/gradebook_history/:date
^ date is like "2013-01-31" ^
/courses/:course_id/gradebook_history/:date/graders/:grader_id/assignments/:assignment_id/submissions
(yes, that last one is huge, but it does follow
the nested structure described by the original
grade book history page).
The user that is selected for testing needs to
have the "manage_grades"
permission on the referenced course. API
documentation is available on the controller class
app/controllers/gradebook_history_api_controller.rb
Change-Id: I18e0b4b967d6c20ad47b86e98adbc15b87276098
Reviewed-on: https://gerrit.instructure.com/17366
QA-Review: Clare Hetherington <clare@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
2013-02-01 08:35:16 +08:00
def api_context ( path )
Api :: V1 :: ApiContext . new ( self , path , @current_user , session , params . slice ( :page ) )
end
end
