There are some important concepts that may be worth highlighting when using the API to interact with rubrics:
- There is (at most) a single rubric associated with a
CourseWorkand that rubric is unique to that
CourseWork(it is not shareable across
- The rubric consists of criteria, which consist of levels. A rubric must always have at least one criteria, and a criterion must always have at least one level.
- Levels can be scored (have points) or unscored (no points). Levels must be
entirely scored or entirely unscored in a rubric.
- If the levels are scored, all levels in a criterion must have a unique points value set. Points can be integers (like 10) or floating point values (like 9.99). This can include 0. Null values are not accepted. Additionally, a rubric can't have a single criteria with a single level that is 0 points.
- If the levels are unscored, the points field should be omitted; null values are not accepted.
- The order for criteria and levels is meaningful and reflects the order they
are represented in the Classroom UI.
- Scored levels in particular must always be sorted by points in either increasing or decreasing order.
- There can be up to 50 criteria per rubric and up to 10 performance levels per criterion.
Related student submission fields
Student submission objects are also changing:
- In addition to the existing
assignedGradeproperties, a student submission graded with a rubric has
assignedRubricGradesproperties. These represent the rubric grades (levels selected and point values) the student receives during grading from the rubric, in the draft and assigned states, respectively.
- For now, these properties are read-only. This means that the API can't be used to grade submissions, but you can read submissions graded in the Classroom UI.
- Student submissions with an associated rubric contain a
rubricIdfield. This field represents the latest rubric associated with the
CourseWork, and this value might change if teachers delete and recreate a rubric.
The API aims to mirror the Classroom UI whenever possible for consistency, but this can lead to behaviour that may be unintuitive for developers and is worth mentioning:
- Rubrics are intended to guide grading without constraining teachers. As a
result, a teacher can do the following when grading a submission with a
- Completely ignore the rubric when grading.
- Override the points for a criterion, irrespective of the points available in the criterion's levels.
- Select levels for only a subset of criteria.
- Assign points for a criteria without selecting a corresponding level.
- Override the assignment's total points, irrespective of the points that would come from the rubric.
Additionally, the API isn't introducing any new product capabilities. In other words, the API doesn't support behavior the Classroom UI doesn't already have. For example, the API doesn't enable enforcing rubrics usage on assignments or overriding a teacher's ability to edit rubrics and submissions as they can today.
Limitations during grading
Similarly, there are some additional limitations place on editing rubrics once a teacher has started grading with it. Only the following edits are possible after grading as started:
- Text edits are allowed for criterion and level titles and descriptions.
- Level ordering can change within criteria.
Rubrics can be manually exported to Google Spreadsheets for re-use by teachers.
If you create or update a rubric from these spreadsheets (see an example in the
guide), your application needs to request the
https://www.googleapis.com/auth/spreadsheets scope. Be aware that the
spreadsheets scopes are considered sensitive and may require your application
to be verified.