LTI Gradebook Services

LTI Gradebook Services
Project state	Planning
Tracker issue	MDL-59403
Discussion	Support for Gradebook services
Assignee	Stephen Vickers

Project goal

The goal of this project is to add support for the LTI Gradebook Services as per the specification available from the IMS website. LTI Gradebook Services allow Tool Providers more control over gradebook columns and scores than currently possible with Basic Outcome. LTI Gradebook Services are in candidate final draft at the time of writing.

Given the importance of the gradebook feature within Moodle and the sensitive nature of gradebook data the guiding principles of this project will be to minimize the impact on the existing gradebook and to ensure best practices with regard to security.

The Gradebook Services allow much more versatility around Grades reporting allowing use cases not achievable under the Basic Outcome model; for example:

• Posting a score for a student no longer requires the student to actually launch the activity;
• There is no longer a requirement to have a Resource Link for each gradebook column; for example, a single link could launch a complex piece of content containing many different assignments, and the instructor can decide which one of those would be reported in the gradebook, without having to also create distinct Resource Links for those.
• On course copy, the resource_id attached to each line item allows the Tool Provider to re-bind to the copied Line Items.

The following diagram presents the 2 interaction models this service makes possible, the programmatic uncoupled one being the new one introduced.

This work is being undertaken with the support of Cengage.

Introduction

LTI Gradebook Services defines three services: LineItem, Result and Score. At a high level, these services provide CRUD operations on gradebook columns (line items) and cells (scores). The specification also defines an API that allows for management of collections of line items within a given context (e.g., a course section), collections of scores for a given line item, as well as for managing individual line items, results and scores (the distinction between results and scores is that scores represent the value as received from the tool provider and are considered immutable by the tool consumer).

The services are secured in the same way as other LTI services, using the same consumer key and shared secret as used for LTI launch messages. All web service payloads use JSON-LD.

LineItem service

Allows line items (gradebook columns) in the Moodle gradebook to be managed by an LTI Tool Provider. Only line items created by (or for) the Tool Provider can be read/updated/deleted by it; this includes line items created by Moodle for the tool provider's links (grade option on Adding a new External Tool). Each line item will be owned by the Tool Provider and associated with a specific context (e.g., course section). The specification does not impose any limits on the number of line items which can be created by a Tool Provider. Of course, a Moodle administrator does not have to make these services available to a Tool Provider. The LineItem service specification defines an API for CRUD operations on a single line item as well as collections of line items.

Score service

Allows scores (gradebook cells) in the Moodle gradebook to be managed by an LTI Tool Provider. In addition to the literal score the score service also allows for the passing of a comment about the grade. The Score service is conceptually similar to the Result service. However, as mentioned above, Score resources should be considered immutable by the tool consumer. The Score service specification defines an API for CRUD operations on a single score as well as the retrieval of the collection of scores for a given item. There is a only a single current Score for a given (user, lineItem) tuple.

Result service The Result service specification defines an API for the retrieval of a single result. Contrarily to the Score, the Result is to represent the actual value shown in the gradebook, which might vary from the score provided by the tool provider.

Variables

The various services are complemented by variables to inject the resource end points in messages; LineItems.url allows access to the collections of line items for the current context and tool provider. It is the main entry point in the gradebook service.

In the case there is a direct association between a resource link and a gradebook column, the Score.url, Scores.url, LineItems.url can also be passed as parameters. The Score.url allows CRUD operation on the score, acting as a direct replacement for the (lis_outcome_service_url, lis_result_sourcedid) tuple from Basic Outcome, while LineItem.url allows access to the associated LineItem and Scores.url is the container for all the scores of the associated line item.

Implementation as a subplugin

The intent is for the service to be first offered as an LTI subplugin. This comes a bit under tension with the overall architecture of the mod_lti plugin where the root of the LTI subsystem is the presence of Link (Activity backed by an LTI activity). As the LTI ecosystem outgrows the sheer concept of link to an external tool, it may have to be revamped a bit. In the meantime, it seems we have found a workable compromise:

• a gradebookservices table will hold the entry to the Line Items created through the API
• a gradebookservices table has a nullable Foreign Key dependency to lti
  • creating a line item with a resourceLinkId would:
    • create a gradebook services line item entry with a Foreign Key to the LTI (or fail if no LTI entry is found to match in the course)
    • create a GradeItem record with iteminstance = lti.id, itemnumber = gradebook services id
  • creating a line item without a resourceLinkId would:
    • create a gradebook services line item entry with null as foreign key to LTI
    • create a GradeItem record with iteminstance = null, itemnumber = gradebook services id

As backup is only called in the context of activity backup, the subplugin backup will have some limited shortcomings:

• for backup to function it will require at least one link for that tool proxy to exist in the course
• each backup for LTI will contain
  • all the gradebook services line items associated to the link
  • all the decoupled line items (this data would duplicated on each link)

Restore will need to handle the duplicate decoupled line items as they are found on each link archive.

Towards a direct integration with mod_lti

As mentioned above, there are some issues with the current mod_lti plugin being considered solely as an activity module as it implies the LTI system is always tied directly to activity in the course. Revising that might prove challenging. Also the dependency between specifications - here the Content Item Selection Request Message containing Line Items definition - seems to call for Gradebook Services Line Item to become a 1st call citizen of the LTI module (i.e. no more a submodule so that the content item handling can inject line items per the content item payload)