This document outlines differences between the 1.1 and 1.2 versions of the OneRoster specification as they relate to Campus's implementation of the specification.
School Scoping
Campus users have the option of scoping the data accessible in the OneRoster API to specific schools. This includes both Rostering and Gradebook data. This option was originally released with OneRoster 1.2 but is now available for OneRoster 1.1 connections that use OAuth 2.0 as well.
Roles
The Orgs collection was replaced by Roles, which define the school the user is associated with and their role at that school. Users can have multiple roles - they are reported in the Users endpoint once, with multiple roles if applicable. For example, a student may be enrolled in multiple schools or a teacher may also have an assignment with a non-teacher role.
- Student: Role types of primary and secondary are mapped to the Service Type selected on the enrollment. If the student has multiple Primary enrollments, the earliest one is returned with a role of primary.
- Aide: Users with an Employment Assignment and any Role other than Teacher.
- Administration: Users with an SIS Security Role.
- Users may be considered as 'aides' and 'administrators.'
- Guardians: Anyone with a relationship to a student that has the Portal checkbox marked on their Relationship.
User SourcedIds
In 1.0 & 1.1, User records only reported one role per person, reporting multiple records for multiple roles. Each of these records had its own sourcedId, prefixed by a letter indicating the type of role (s for student, t for teacher, etc). In 1.2, User records can have multiple roles but only have one sourcedId, which does not have a role-specific prefix. Thus, sourcedIds are not backwards compatible prior to 1.2. However, Campus provides the metadata.ic.legacysourceId value, which is the legacy sourcedId without the role prefix. For example, if a (student) user's sourcedId in 1.1 was s+123456, their legacy sourcedId would be 123456. This value may be useful to connect records between 1.2 and prior versions.
Note: userMasterIdentifier returns the StateID for all students.
User Accounts not Required
To report, users are no longer required to have user accounts. However, if user accounts are present, their actual username is reported in the User Profiles collection, not the User object. Username is populated as the Identifier and the type is hardcoded as 'infiniteCampus'. All usernames report for a user; Campus does not determine the primary username. Passwords are not included.
Because user accounts are no longer required, the GETALL Demographics endpoint may be larger than in previous versions.
Categories & Score Scales
The main changes to the Gradebook endpoints is that Category and Score Scale are now required and included in score LineItems received by Campus. Including this data in the LineItem endpoint means that synced assignments are fully integrated in the Campus Grade Book and teachers will no longer need to categorize and align OneRoster assignments.
Categories
Previously, a Category of all 1's was auto-filled for assignments, requiring teachers to categorize and align assignments received through the OneRoster API. Now that Categories are included in the specification, this auto-filled category of 1's has been removed. Score lineItems are now aligned to real categories instead.
As a result of this change, the GETALL Categories endpoint reports all Categories in all classes (LessonPlanGroup records). Because many classes may have categories with duplicate names, the GETALL endpoint for Categories likely won't be very useful. Campus recommends using GETALL Categories for a Class to provide more relevant data.
Score Scales
The Score Scale is determined using the Task the score is aligned to and the Score Group used to determine the grade.
For example, a section has two Tasks, one for Quarter grades and one for Semester grades. Both tasks have a Score Group of A-F. The Score Group identifies the possible grades the student can receive on the task (A, B, C, etc) and the percentage thresholds for those grades (A = above 90%, B = above 80%, etc). In this example, two Score Scale records are returned for the section: Quarter A-F and Semester A-F.
Score Statuses
The following table maps OneRoster scoreStatus values to the flags available in the Campus Grade Book and provides a priority for aligning those flags. In some instances, an assignment can have multiple flags in Campus.
scoreStatus | Campus Flag | Priority |
---|---|---|
Exempt | X - Exempt | 3 |
Fully Graded | No flag | |
Not Submitted | M - Missing | 1 |
Partially Graded | No flag | |
Submitted | No flag | |
Late | L - Late | 5 |
Incomplete | I - Incomplete | 6 |
Missing | M - Missing | 1 |
Withdrawal | Dr - Dropped | 4 |
In Progress | No flag | |
No flag | Ch - Cheated | 2 |
No flag | T - Turned In | 7 |
Additional Information:
All Gradebook endpoints still require Campus districts to have a Campus Learning license.
Endpoint | Change |
---|---|
GETALL and GETONE Students w/o roles |
User SoucedIds in 1.2 are not backwards compatible with 1.1. See SourcedId section above for more info. |
GETALL Classes | Does not include grade levels, which is part of the specification. Campus does not limit sections by grade level. Endpoint returns all sections for the current school year. |
GETALL and GETONE Demographics | Any Gender value other than M or F reports as O: Other. |
GETALL and GETONE Teachers |
|
GETALL and GETONE Users | This endpoint is a concatenation of Students and Teachers and also includes Administrators (Staff with a role other than teacher) and Guardians (people with a relationship to a student with the Portal checkbox marked) |
GETALL and GETONE LineItem | Category and School have been added to this endpoint. |