ylqjgm
/
canvas-lms
mirror of https://github.com/instructure/canvas-lms.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
canvas-lms/app/controllers/gradebook_history_api_contr...

323 lines
12 KiB
Ruby
Raw Normal View History

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
#
# Copyright (C) 2013 Instructure, Inc.
#
# 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.
#
#
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# {
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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.",
# "example": "[]",
# "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
# }
#
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# {
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# }
#
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# {
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# }
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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
# {
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
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",
# "example": "[]",
# "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
# }
#
converting @object notation to @model part 7/11 converting for: grade book history controller group categories controller group membership controller groups controller migration issues controller Contributed by github.com/mcgachey Fixes SIS-146 Currently, some API objects are documented using the @object tag, and others are documented using @model. The @model tag is preferred because it provides more information in the machine-readable Swagger documents generated by the API documentation build step. For example, the @object notation does not give a way to specify that a model property contains an instance of another type. This complete information is necessary in order to build an SDK generator. This change converts the @object notations into @model, adding missing type information and correcting inaccurate data (for example, dates were typed as "string" in the existing JSON documentation). Embedded types are also separated out so that their format can also be documented - this information was previously lost. The change also makes two minor fixes to the HTML and JSON documentation generators. The HTML generator is fixed so that a missing documentation string is ignored rather than being shown as an empty comment, and the JSON generator is modified so that the Model-level documentation and required attributes are properly provided. Note that the JSON generated here is not fully-complient to the Swagger format. Swagger does not support a Map structure, but the Canvas API uses (semi-)arbitrary key/value dictionaries in a few places. In those instances the properties are typed as "map", but this is not a part of the Swagger spec. Any cleaner alternative approaches here would be welcome. Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b Reviewed-on: https://gerrit.instructure.com/30001 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Rob Orton <rob@instructure.com> Product-Review: Rob Orton <rob@instructure.com> QA-Review: Rob Orton <rob@instructure.com>
2014-02-12 07:21:09 +08:00
class GradebookHistoryApiController < ApplicationController
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
before_filter :require_context
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2013-04-18 01:40:52 +08:00
before_filter :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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2013-04-18 01:40:52 +08:00
days_hash = days_json(@context, api_context(api_v1_gradebook_history_url(@context)))
to_json unnecessary (and wrongish) in render :json refs CNVS-7597 render :json => thing will call ActiveSupport::JSON.encode(thing) unless thing is a String. ActiveSupport::JSON.encode(thing) just calls thing.to_json but with some circular reference checking that we want. we may also want enhance ActiveSupport::JSON.encode to do additional processing, and calling to_json straight up would bypass that. in the cases where we do need to do the structural transformation before passing to render :json (e.g. because of need to pass arguments), use as_json to do structural transformation only, vs. to_json that does serialization of the as_json result. adds a rake task to lint the controllers to enforce as_json over to_json in render json calls. test-plan: heavy regression testing; no end behavior should change (except a pair of serialization bugs that got fixed) Change-Id: I7a91a9fe0eca70456bc5bca233f0ed6b27a54aaf Reviewed-on: https://gerrit.instructure.com/23650 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>
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.
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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))
to_json unnecessary (and wrongish) in render :json refs CNVS-7597 render :json => thing will call ActiveSupport::JSON.encode(thing) unless thing is a String. ActiveSupport::JSON.encode(thing) just calls thing.to_json but with some circular reference checking that we want. we may also want enhance ActiveSupport::JSON.encode to do additional processing, and calling to_json straight up would bypass that. in the cases where we do need to do the structural transformation before passing to render :json (e.g. because of need to pass arguments), use as_json to do structural transformation only, vs. to_json that does serialization of the as_json result. adds a rake task to lint the controllers to enforce as_json over to_json in render json calls. test-plan: heavy regression testing; no end behavior should change (except a pair of serialization bugs that got fixed) Change-Id: I7a91a9fe0eca70456bc5bca233f0ed6b27a54aaf Reviewed-on: https://gerrit.instructure.com/23650 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>
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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
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
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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])
to_json unnecessary (and wrongish) in render :json refs CNVS-7597 render :json => thing will call ActiveSupport::JSON.encode(thing) unless thing is a String. ActiveSupport::JSON.encode(thing) just calls thing.to_json but with some circular reference checking that we want. we may also want enhance ActiveSupport::JSON.encode to do additional processing, and calling to_json straight up would bypass that. in the cases where we do need to do the structural transformation before passing to render :json (e.g. because of need to pass arguments), use as_json to do structural transformation only, vs. to_json that does serialization of the as_json result. adds a rake task to lint the controllers to enforce as_json over to_json in render json calls. test-plan: heavy regression testing; no end behavior should change (except a pair of serialization bugs that got fixed) Change-Id: I7a91a9fe0eca70456bc5bca233f0ed6b27a54aaf Reviewed-on: https://gerrit.instructure.com/23650 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>
2013-08-23 06:22:14 +08:00
render :json => submissions_hash
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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+.
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2014-08-06 23:29:54 +08:00
# @argument course_id [Required, Integer]
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2013-04-18 01:40:52 +08:00
# The id of the contextual course for this API call
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2014-08-06 23:29:54 +08:00
# @argument assignment_id [Integer]
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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.
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2014-08-06 23:29:54 +08:00
# @argument user_id [Integer]
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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.
#
update API doc required params - 6 - Feature flags - Files - Grade change log - Gradebook history - Grading standards Test plan: - rake doc:api - Verify the above doc pages for parameter accuracy Refs SIS-403 Change-Id: I52627a9bd557682c12713455e989d2e054c744b6 Reviewed-on: https://gerrit.instructure.com/38808 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Tyler Pickett <tpickett+gerrit@instructure.com> Product-Review: Tyler Pickett <tpickett+gerrit@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com>
2014-08-06 23:29:54 +08:00
# @argument ascending [Boolean]
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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
path = api_v1_gradebook_history_feed_url(@context, params)
indexed_versions = Api.paginate(indexed_versions, self, path)
use rails 4.2 preloader format closes #CNVS-26031 Change-Id: I2e0351fb62e5a06b47fe8c6c3dd503318d29a7ad Reviewed-on: https://gerrit.instructure.com/69228 Reviewed-by: Cody Cutrer <cody@instructure.com> Tested-by: Jenkins Product-Review: James Williams <jamesw@instructure.com> QA-Review: James Williams <jamesw@instructure.com>
2015-12-19 05:47:46 +08:00
ActiveRecord::Associations::Preloader.new.preload(indexed_versions, :version)
gradebook history api: ignore deleted submissions the 'feed' action in the gradebook history api controller will no longer error due to submissions being deleted. closes CNVS-25114 test plan: * hit the gradebook_history_api_controller#feed and verify you get back a list of submissions * pick any one of the submissions from the list, and delete it. you will need to do this via the rails console. if you want to delete a submission with id 5, this would look like: Submission.find(5).destroy * hit the gradebook_history_api_controller#feed again, and verify you get back a list of submissions. before this fix, this api call would return an error. Change-Id: I9dfaa270a8d0fae8150fc0c36f8343887c2c5d18 Reviewed-on: https://gerrit.instructure.com/67370 Tested-by: Jenkins Reviewed-by: Strand McCutchen <smccutchen@instructure.com> QA-Review: Jason Carter <jcarter@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-11-18 07:36:08 +08:00
versions = indexed_versions.map(&:version).compact
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2013-04-18 01:40:52 +08:00
standardize the submission history api response format The submission history formatter was returning a lot of data that it shouldn't, and it wasn't going through the standard api_json helpers. This commit modifies Api::V1::SubmissionHistory to use Api::V1::Submission for the json formatting with the extra fields added afterwards, and updates the documentation and tests to match. fixes CNVS-5581 test plan: use the submission history api endpoints, including the new feed endpoint. you should get submission history objects back in the new format described -- it's a superset of the normal submission api response object. Change-Id: I01f6a1eacae5a1d6644dbd5b151fb41fe04eb469 Reviewed-on: https://gerrit.instructure.com/20184 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Brian Palmer <brianp@instructure.com>
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
add gradebook history feed API endpoint fixes CNVS-2802 test-plan: - create a course with multiple students and assignments - create submissions for those students and assignments - grade the submissions, including multiple gradings of some of them - GET /api/v1/courses/X/gradebook_history/feed - each grading should match the SubmissionVersion object described in the API docs - should include gradings for any assignment and student in the course - should include all gradings for any submission that's been graded multiple times - should paginate the returned gradings - should order the most recent gradings first - GET /api/v1/courses/X/gradebook_history/feed?assignment_id=Y - should only return gradings for submissions on that assignment - GET /api/v1/courses/X/gradebook_history/feed?user_id=Z - should only return gradings for submissions by that user - GET /api/v1/courses/X/gradebook_history/feed?ascending=1 - should order the oldest gradings first - Repeat with combinations of the various parameters Change-Id: I44aae11919116519f87a097f2d5cf1849acc4db3 Reviewed-on: https://gerrit.instructure.com/19680 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
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