[QTI] Show the unsupported message for QTI items with multiple or unsupported interactions

❌ This issue is not open for contribution. Visit Contributing guidelines to learn about the contributing process and how to find suitable issues.

Overview

The QTI editor shows an unsupported message for items it cannot read, but not for QTI items it can parse and still cannot edit faithfully. An item with more than one interaction is rendered from its first interaction alone, and an item whose interaction no descriptor resolves is rendered as something it is not, or as an empty question. Both cases should be recognized and shown as unsupported. If we don't have at least one and only one interaction, the editor should not support it.

Complexity: Medium
Target branch: unstable

Context

parseItem.js collects every interaction element in the item body, but QTIItemEditor/index.vue seeds its editor state from interactions[0] only and renders a single InteractionSection. Because the item's XML is reassembled from that seeded state, a second interaction is dropped rather than merely hidden.

isUnsupported in the same component currently covers only non-QTI item types and parse failures, and the unsupportedItemMessage$() string already exists for it.

Unrecognized interactions arrive in two shapes:

• A tag absent from QTI_INTERACTION_TAGS (e.g. qti-hotspot-interaction) is never collected, so interactions is empty and the item falls through to the empty-question placeholder.
• qti-match-interaction and qti-extended-text-interaction are in QTI_INTERACTION_TAGS but have no registered descriptor, so resolveDescriptor falls back to DEFAULT_INTERACTION and the item renders as a choice question.

The Change

An item should be treated as unsupported when it contains more than one interaction, or when no supported interaction could be discovered in it — whether because nothing in the body matched a known interaction tag, or because nothing that did match resolved to a registered descriptor. An item resolved by descriptor fallback should no longer be presented as the fallback question type.

QtiInteraction should list every interaction element defined by QTI 3.0, not only the ones this editor can edit. Detection depends on it: an interaction missing from that list is invisible to the item body query, which makes "we found a question we cannot edit" indistinguishable from "we found no question at all".

These items should show the existing unsupported message, and the card should expose no editable controls, hints included. An unsupported item's XML should reach the server exactly as it arrived.

Additionally, since we always need at least one valid interaction, we don't need a DEFAULT_INTERACTION constant; remove any code path that uses it.

How to Get There

These items cannot be produced through the authoring UI — both cases require an assessment item whose raw_data was written elsewhere, such as a channel uploaded via ricecooker. utils/testingFixtures.js already carries item documents for the unknown-interaction and no-interaction cases; a multi-interaction document is not yet among them.

To see the current behavior, open an exercise in the channel editor with an item whose XML contains two interactions: the card renders the first one and the second is absent.

Out of Scope

• Descriptors or editors for the interaction types added to QtiInteraction. They are listed so detection can recognize them, not so they become editable.
• Editing items that contain more than one interaction. This task flags them; it does not make them work.
• The unsupported cases already handled — non-QTI item types and parse failures keep their current behavior.

Acceptance Criteria

• QtiInteraction lists every interaction element defined by QTI 3.0
• An item containing more than one interaction is treated as unsupported
• An item in which no supported interaction could be discovered is treated as unsupported, covering both an interaction with no registered descriptor and a body with no recognized interaction element
• An item whose interaction has no registered descriptor is no longer presented as the fallback question type
• Unsupported items show the existing unsupportedItemMessage$() string
• An unsupported item's card exposes no editable controls, including hints
• An unsupported item's raw_data is unchanged after the item is opened
• Items with a single supported interaction continue to open in the editor as they do today
• Fixtures for a multi-interaction item and an unrecognized-interaction item are added to utils/testingFixtures.js
• Unit tests cover the detection of each unsupported case and confirm supported items are not caught by it
• A component test asserts the unsupported card shows the message and renders no editable controls
• A test asserts an unsupported item's XML round-trips unchanged
• Remove the DEFAULT_INTERACTION constant and any code path using it.

References

• QTI v3 Best Practices and Implementation Guide — section 3 lists the QTI 3.0 interactions and their shared vocabulary
• QTI 3.0 Assessment, Section and Item Information Model — the normative element definitions

AI usage

I used Claude Code to draft this issue. It read the QTI editor's parsing and item components to confirm the current behavior; I made the scoping decisions and reviewed every section.

Start with parseItem.js and QTIItemEditor/index.vue to trace interaction collection, descriptor resolution, and the existing unsupportedItemMessage$() path. Inspect the QTI item fixtures in utils/testingFixtures.js and add coverage for multi-interaction, unrecognized, descriptor-fallback, and supported cases. Done means unsupported cards have no editable controls, their raw XML round-trips unchanged, and supported single-interaction items retain current behavior.