Feature Wiki

Information about planned and released features

Tabs

Advance grading service

Page Overview

[Hide]

1 Initial Problem

ILIAS supports LTI (including LTI 1.3) but does not yet provide full support for the LTI 1.3 Assignment and Grade Services (AGS) that modern LTI Advantage tools expect for grade return and richer assessment reporting. The LTI feature roadmap explicitly lists adding “LTI 1.3 Advanced Grading Service” as a planned long-term improvement.

As a result, institutions integrating external tools (quizzes, labs, coding environments, etc.) face one or more of these problems:

  • External tools cannot reliably return grades to ILIAS using the standard LTI Advantage mechanism (AGS)
  • Only “basic” or tool-specific integrations are possible, reducing interoperability and raising maintenance costs
  • Instructors lack a consistent way to configure whether an LTI activity is gradable, how many grading columns it provides, and how comments/attempt history should be handled

Goal: Implement LTI 1.3 AGS in ILIAS to allow standards-compliant grade exchange between ILIAS and external LTI tools.

2 Conceptual Summary

Implement LTI 1.3 Assignment and Grade Services (AGS) endpoints and internal persistence/mapping so that:

  1. ILIAS (Platform / Consumer) exposes the AGS REST APIs to authenticated LTI tools:
    • Line Items service (gradebook columns for a resource link)
    • Scores service (posting scores / attempts)
    • Results service (retrieving results, optional comments, etc.)
  2. ILIAS provides configuration UI for administrators and course authors:
    • Enable/disable AGS per registered LTI 1.3 tool
    • Configure which AGS scopes are allowed per tool
    • Configure behavior per LTI placement / repository object (e.g., single column vs multiple columns, max score, whether comments are stored)
  3. ILIAS stores received grade data in a consistent way and exposes it in the most appropriate existing ILIAS result surfaces (depending on ILIAS’ current grading architecture), while minimizing invasive changes:
    • Map LTI line items to ILIAS “gradable items” associated with the LTI object
    • Store scores (with timestamp, activity progress, submission attempt number if provided)
  4. Implementation follows LTI 1.3 security:
    • OAuth2 access tokens with scopes required by AGS, validated server-side
    • Strict authorization: a tool can only access lineitems/scores/results for the specific context/resource-link it is entitled to

3 User Interface Modifications

3.1 List of Affected Views

  • Repository Object (LTI Consumer / External Tool) > Settings
  • Repository Object (LTI Consumer / External Tool) > (New) Grading / Outcomes tab

3.2 User Interface Details

  • Checkbox: This activity is gradable
    • If checked: ILIAS includes AGS-related launch claims and allows grade exchange
    • If unchecked: AGS disabled at this link level (even if tool supports it)

A new tab that shows per-user grading status for this LTI activity.

Elements:

  • Table: columns
    • User
    • Score
    • Activity progress
    • Date
    • Grading progress
  • Filters: user search; column filter

3.2.1 Behavior rules

  • Teachers/Tutors see all
  • Learners see only their own results (if allowed by ILIAS result visibility settings)

3.3 New User Interface Concepts

No completely new UI concepts are required if the implementation uses existing ILIAS UI building blocks.

3.4 Accessibility Implications

The Form in Administration is only based on KS-Elements, therefore there are no Accessibilty Implications.

4 Additional Information

4.1 Technical Aspects

4.1.1 Standards / APIs

Implement LTI 1.3 Assignment and Grade Services (AGS) per 1EdTech specification. AGS replaces Basic Outcomes and allows tools to create/manage multiple gradebook columns and exchange scores/results/comments.

4.1.2 Endpoints

  • GET/POST lineitems (list + create)
  • GET/PUT/DELETE lineitems/{id} (manage)
  • POST lineitems/{id}/scores (submit score)
  • GET lineitems/{id}/results (retrieve results)

4.1.3 Authentication / Authorization

  • OAuth2 bearer tokens as used in LTI 1.3 services; validate:
    • Token signature / issuer / audience
    • Expiry
    • Scope checks per endpoint
  • Authorization checks must ensure a tool can only operate within the context/resource-link it was launched for

4.1.4 Data model

  • Tool registration (existing)
  • Context + resource link mapping (existing LTI consumer model)
  • lti_ags_lineitem table:
    • internal id, tool registration id, context id, resource link id, label, max score, external lineitem id/url, timestamps
  • lti_ags_score table:
    • lineitem id, ilias user id, scoreGiven, scoreMaximum, activityProgress, gradingProgress, comment (optional), timestamp, attempt number (optional), raw JSON (optional for debugging with retention policy)

4.1.5 Performance considerations

  • Avoid synchronous calls during page rendering; display stored results
  • Index by (lineitem_id, user_id) and by (context/resource_link) for fast retrieval
  • Consider background cleanup / retention policy for score history

4.1.6 Dependencies

  • Depends on existing LTI 1.3 platform implementation in ILIAS (JWT validation, key management, registration UI)
  • UI should be built using the current/target ILIAS form framework (the LTI roadmap mentions updating forms for consistency)

4.2 Privacy

Personal data processed/stored:

  • ILIAS internal user identifier (e.g., user_id): Needed to associate posted scores/results with the correct learner.
  • LTI subject / user mapping (depending on existing LTI design): Needed to map LTI launch identity to an ILIAS user (often already exists for LTI).
  • Grades / scores: Numeric grade values are personal performance data; needed to display results and support grading workflows.
  • Timestamps / attempt history: Needed for traceability (“when was the grade posted?”) and optional attempt tracking.

4.3 Security

Key security topics for AGS implementation:

  • Token validation & scope enforcement
    • Every AGS request must be authenticated and checked for correct scope (principle of least privilege).
  • Context/resource-link authorization
    • Ensure a tool cannot write scores for:
      • Other courses/contexts
      • Other resource links
      • Other tools’ line items
  • Input validation
    • Validate numeric ranges (scoreGiven ≤ scoreMaximum; scoreMaximum > 0)
    • Prevent injection via comments/labels (escape output, enforce length limits)
  • Data exposure
    • Results endpoints must not leak other users’ grades to learners; enforce role-based access or only expose to tools as per spec and local policy

4.4 Contact

4.5 Funding

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

  • ...

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.

Full Screen

Last edited: Yesterday, 13:02, Santiago, Sergio [sergiosantiago02]