For Developers
Implementation Details
The Skyward Qmlativ uses OneRoster for grade passback.
Entity Mapping
This document explains how Qmlativ entities are mapped to Edlink entities.
| Qmlativ Entity | Edlink Entity |
|---|---|
| Course | Course |
| Department | Department |
| Enrollment | Enrollment |
| GradingPeriod | Session |
| Guardian | Person, Agent |
| Section | Section |
| Staff | Person |
| Student | Person |
| Subject | Subject |
| OneRoster Entity | Edlink Entity |
|---|---|
| Category | Category |
| LineItem | Assignment |
| Result | Submission |
Notes
student_gpa_method_nameis a configurable property which controls how GPAs are calculated. By default we use the'Weighted'method.- From what we have found, sections (classes) are related to grading periods (sessions) based on multiple fields.
By using a combination of the two fields from the section we can uniquely isolate which grading period it belongs to.
However, we are NOT going to assume that grading period descriptions are unique within a set that has the same
SectionLengthID. Therefore, we will support the possibility of sections referencing multiple grading periods, although we expect they almost always only reference one.SectionLengthID- This field exists on both the section and the grading periodCurrentGradingPeriod- This field is on the class and seems to reference the grading period "Description" field.
- Not all Qmlativ instances have support for the same requested fields. For example, Qmlativ instances for Texas districts have different demographic tables/fields that those in Illinois or Indiana. Furthermore, administrators can configure their Qmlativ instances to prohibit reading of specific databases, tables, and/or fields. So, if you encounter missing fields on an object, first verify that it exists in the Qmlativ instance, and that it is shared.
Custom Field Mapping
The following fields can be custom-mapped in our dashboard UI:
- agent relationships