Moodle LMS Integration

LTI (Learning Tools Interoperability) is a standard that connects a learning management system, such as Moodle, to an external learning tool. With LTI 1.3, users open Qriib from their course, and the LMS securely supplies their identity, course context, and role. Qriib uses that verified context to determine access to the classroom.

This guide connects Moodle to Qriib through the LMS Integration setup wizard. An administrator registers the connection first; instructors then add the tool to a course and verify a launch.

Before You Start

• Access to the correct Qriib organization as an authorized owner or admin.
• A plan with LMS integration enabled and capacity for the registration. Only one active LMS registration is allowed.
• Moodle administrator access to configure the LTI 1.3 tool.
• Two browser tabs: the Qriib portal and Moodle, so you can copy configuration values between them.

Open LMS Integration in your Qriib portal. For the development environment, use the LMS Integration page. Use your organization's corresponding portal for other environments.

Qriib Setup Flow

Screenshots below show the current Qriib setup components in a local preview with example values. Copy URLs and identifiers from your own portal and LMS; the screenshots do not represent a live LMS registration.

Next validates the current step before continuing. After a successful save, the page shows Registration saved and Launch not verified here. Finish the course setup and launch the tool from Moodle to verify the connection. Saving configuration alone does not test an LMS launch.

Key Capabilities

Workspace features depend on the verified course role, organization entitlement, and current resource state. Attendance reports/manual attendance, automatic AGS grades, CSV export, and readiness filters remain pending. Controls still marked Soon, commented out, or disabled remain Partially Complete / Pending Frontend Activation.

The setup instructions follow the current portal source as of November 5, 2026. Verify the connection with a course launch in your environment. The Phase 2 verification report records earlier source-alignment checks.

Step 1: Choose Moodle and Copy the Tool URLs

1. Log in to your Qriib DevKit Portal.
2. Navigate to LMS Integration from the sidebar.
3. In Platform, select Moodle and confirm the organization and prerequisites. Select Next.
4. In Tool URLs, copy the environment-specific OIDC Initiation URL, Target Link URI (Launch URL), and Public Keyset URL (JWKS). If URLs are unavailable, obtain them from your Qriib administrator before configuring Moodle.

Use the copy button beside each URL. If clipboard access fails, select the URL and copy it manually. These are Qriib tool URLs; the Moodle platform URLs will be entered later in LMS details.

Keep this tab open — you will paste these into Moodle in the next step.

Platform Selection

Copy the Tool URLs

LTI management requires fresh verified Control Panel owner or admin membership in the target organization. A Moodle administrator or instructor role does not grant Qriib management access. Ordinary members, foreign integrations, and missing organization mappings are denied; unavailable verification fails closed. Management responses distinguish 401 invalid_lti_management_token, 403 forbidden_lti_management, and 503 lti_management_authorization_unavailable.

Step 2: Configure External Tool in Moodle

1. Log in to Moodle as a Site Administrator.
2. Navigate to: Site Administration → Plugins → Manage tools.
3. Click Configure a tool manually.

4. Fill in the configuration form with the following values:

5. Expand Services and Privacy sections and set:

6. Click Save Changes.

Optional: Set Your Institution's Workspace Logo

To display your institution's logo in the Qriib workspace header, add a custom parameter to the external tool. This requires a Qriib environment with client-logo support deployed on both the backend and frontend.

1. Go to Site administration > Plugins > Activity modules > External tool > Manage tools. Navigation labels may vary by Moodle version.
2. Find your Qriib Virtual Classrooms tool and open its edit/settings form.
3. Find Custom parameters, expanding Show more if necessary.
4. Add the following on a separate line, preserving any existing parameters:

logo_url=https://your-university.edu/assets/logo.png

5. Click Save Changes.
6. Close the existing workspace and launch the activity again from your course. Refreshing an existing workspace keeps the logo from that session's original launch.

Use a direct image URL, not a webpage containing an image. For example, a Wikipedia /wiki/ file page returns HTML and cannot be displayed as the logo. Open Original file on that page to obtain the direct image URL instead.

The image must be publicly accessible over HTTPS, without login or authorization headers. Open it in a private browser window to check that it loads. Use a stable URL without temporary access tokens; PNG, JPEG, WebP, and SVG images are suitable. The header preserves aspect ratio within a 96px-wide by 32px-high area.

Icon URL and Secure icon URL change the icon displayed inside Moodle. They do not automatically set the Qriib workspace logo; use the explicit logo_url custom parameter above.

If the logo is missing, invalid, or fails to load, the workspace displays a neutral school icon and remains usable. The external image host receives the browser's image request and network metadata; the workspace sends no referrer or LTI authorization header.

Troubleshooting the Logo

In browser Developer Tools, open Network and inspect the authenticated /lti/v1/workspace response. Check only its branding object; do not share authorization tokens or launch JWTs.

Step 3: Register Moodle Credentials in Qriib

After saving, Moodle generates platform credentials you must register back into Qriib:

1. In Moodle Manage Tools, find your Qriib Virtual Classrooms tool card.
2. Click View Tool Details.
3. Copy the following parameters:

4. Return to Qriib DevKit Portal → LMS Integration and continue from Tool URLs to LMS details.
5. Paste the issuer, client ID, deployment ID(s), and the three LMS endpoint URLs. Leave Authentication Audience blank unless your LMS requires it.
6. Select Next to open Review. Check the organization, platform, identifiers, and URLs, then select Register LMS Integration.
7. Confirm Registration saved. Launch not verified here means the configuration was saved; launch the tool from a Moodle course to verify the connection. If saving fails, your entries remain available so you can correct them and save again.

Only one active LMS registration is allowed. When editing an existing registration, issuer and client ID are fixed; a different identity requires a new registration.

Copy the issuer exactly, including any trailing slash. Registration endpoints require HTTPS; HTTP is allowed only for explicit loopback hosts (localhost, 127.0.0.1, ::1) in local development. Embedded credentials and unsafe URL forms are rejected. Creation and re-enabling both require synchronized Control Panel LTI entitlements and available integration capacity.

Enter the LMS Details

Review Before Saving

Registration Saved

The saved screen confirms that the configuration was stored. Continue below to open the tool from an LMS course and verify the launch.

Step 4: Add Virtual Classrooms to Courses (Instructor Workflow)

Instructors add Virtual Classrooms directly inside their respective Moodle courses (not in Site Administration):

1. Go to My courses from the Moodle navigation bar and open your course (e.g., CS501 Computer Science).
2. Toggle Edit mode ON in the top-right corner of the course page.
3. Click Create course (or select an existing course).
4. Click Participants in the course menu and click Enrol users.
5. Select users, set Assign role to Teacher (or Student), and click Enrol users.
6. Click More in the course top navigation bar.
7. Select LTI External Tools.
8. Find Qriib Virtual Classrooms and toggle Show in activity chooser to ON (active).
9. Return to your course section, click + Add an activity or resource, and select Qriib Virtual Classrooms.
10. Provide an Activity Name (e.g., CS501 Live Lecture).
11. Review the Privacy section according to your institution's data-sharing policy. Accepting grades is not required for the current Qriib meeting workflow.
12. Do not configure a points grade expecting automatic attendance passback; this release does not publish it.
13. Click Save and return to course.

Open the saved activity to launch the workspace. Check that the correct course and instructor identity appear. If the activity setup uses Deep Linking, the instructor completes its content-selection confirmation during setup; learners open the resulting saved activity. Verify a learner launch separately to confirm the permitted learner view:

Workspace Roles & Capabilities

The backend determines the user's course role and capabilities from the validated launch. LMS administrator status alone does not grant every workspace action. The Workspace, Recordings, and instructor History tabs appear according to those capabilities.

Instructor View

When the backend recognizes an instructor with meeting-creation permission, Create Quick Meeting opens a confirmation to start a classroom:

Learner (Student) View

Phase 2 Safety Rules

These rules also apply to the shared LTI backend used by Canvas. LMS-specific setup does not override them.

Grades Remain Pending

Ordinary meeting end has no automatic attendance-grade side effect. The production debug_ags route and forced prototype grade capability are removed. A reusable AGS library remains in the backend, but that is not an activated grading or attendance feature. Enabling LMS grade services does not change this policy.

Authenticated Recording Playback

Playback requires two authenticated POST requests, not opening the capability URL directly:

1. POST /lti/v1/recordings/{recording_id}/access with the workspace bearer returns {"access_url":"https://configured-api.example/lti/v1/recordings/access/<capability>"}.
2. Validate that URL against the configured backend origin and expected consumption path, then POST /lti/v1/recordings/access/{capability} with the originating workspace bearer, redirect: error, and no-store/no-referrer policy. Success returns 200 {"url":"https://media-provider.example/..."}.
3. Navigate the synchronously reserved, detached tab to the HTTPS provider URL without authorization headers. Popup blocking or an error closes/stops this flow; it is not a reason to bypass consumption.

Never put a workspace bearer in a URL, send it to arbitrary returned origins or redirects, or fetch the media-provider URL with it. The frontend rejects consumption URLs outside the configured API origin/path and rejects unsafe provider navigation schemes. Consumption responses use no-store and no-referrer policies.

Version-2 capabilities are short-lived (default 120 seconds), atomic, single-use, and bound to the originating session and identity. They store a session digest and recording identity, not the raw bearer or provider URL. Consumption rechecks the live session, active integration/course, current local membership/role, entitlement, recording ownership/deletion, and publication visibility. Consumed attempts cannot be replayed; a failed service-level check after atomic consumption burns the capability. External LMS membership freshness depends on synchronization, not a live Moodle lookup.

Coordinate frontend and backend rollout. Anonymous GET consumption is retired (405); legacy URL-only capabilities are rejected. Old GET-based clients will fail. Use the matching client and request a fresh capability. Revocation/expiry or unpublishing can prevent unused capability access; it does not promise revocation of provider URLs already returned. Browser popup/network/stale-result checks and deployed origin/header checks remain release gates.

Force Disable Is Not Termination Proof

Normal disable refuses live rooms with 409 lti_live_meetings. Force disable is an explicitly approved incident action, not routine registration recovery. It disables launch access even when remote room termination is unresolved.

Inspect termination_outcomes and reconciliation_required; HTTP 200 alone does not prove every room ended or every concurrency lease was released. Only confirmed termination permits setting local end_at and attempting lease release. failed or unknown leaves room/lease state unchanged; failed lease release retains its identifier. Durable unresolved markers live in existing Rooms.extra_data.lti_force_disable metadata.

Authorized owners/admins can discover unresolved markers using GET /management/v3/lti-integrations/{id}/reconciliation, including ended rooms with retained leases. Repeating disable on an already-disabled integration reports persisted uncertainty without retrying remote termination. Enable restores only courses disabled by that platform operation; it neither clears markers nor proves termination or lease release. Do not cycle disable/enable to recover an incident.

Follow backend docs/lti/force-disable-reconciliation.md: obtain approval, verify the specific room occurrence using authoritative provider evidence, use the reviewed recovery dry run before separately approved apply, and verify durable local state and actual lease release independently. A timeout, UI badge, local end timestamp, or empty discovery list is not provider proof. There is no public automatic force-retry or marker-clear endpoint in this phase.

English And Arabic

Initial language comes only from launch_presentation.locale in the validated LTI launch. Supported English/Arabic and regional forms such as en-US, ar-SA, and ar_EG normalize to en/ar. Missing, unsupported, or malformed values fall back to the configured supported route language, otherwise English. Automatic Moodle-language selection therefore depends on Moodle actually sending this verified claim.

Locale is retained in server-owned exchange/session context, including deep linking. Only the known language segment of a trusted configured /{en|ar}/lti[/deep-link] path is rewritten; origin, base path, query, and trailing slash are preserved. Custom unlocalized routes remain unchanged. Browser input cannot select an arbitrary redirect origin.

The workspace's English/Arabic selector changes the localized route, dictionary, and direction for the current workspace session, preserving its per-tab session and selected tab/scopes. It removes the launch fragment rather than exchanging a consumed code again. Switching is guarded during mutations or unresolved reconciliation; close forms/dialogs/menus first. It does not translate user titles or alter stored timestamps, and no global preference overrides the next launch's own language. Actual EN/LTR and AR/RTL provider/navigation/browser acceptance remains a separate verification gate.

Independent Logout

Authenticated POST /lti/v1/session/logout revokes the Qriib workspace session. Its independent TTL defaults to 3600 seconds and is deployment-configurable. Expiry/revocation prevents subsequent bearer use, including unused recording capability consumption.

Moodle cookies, workspace sessions, and management/Keycloak sessions are separate. Closing a tab or logging out of Moodle does not prove workspace logout ran, and workspace logout does not log out Moodle. No trusted Moodle logout notification contract or synchronized logout is implemented. A meeting-engine logout_url is navigation, not an authenticated Moodle logout signal. Do not substitute cookie polling, unsigned browser messages, or broader CORS. Cross-system logout requires a separately approved, authenticated, replay-protected deployment contract; already returned media URLs remain outside workspace revocation guarantees.