Add a QTI assessment-item type and renderable preset-bit ordering #224

Activity

1. rtibbles

   added

   enhancement

   on Jun 28, 2026
2. rtibbles

   marked this as blocking 3 issues on Jun 28, 2026

   • [QTI] Allow API endpoint to handle AssessmentItem.raw_data to store QTI data studio#5999
   • [QTI] Publish mixed Perseus + QTI exercises as one QTI package studio#6006
   • [QTI] Use File.included_presets for more comprehensive import renderability gating kolibri#14893
3. rtibbles

   added the

   Task

   issue type on Jun 28, 2026
4. rtibbles

   assigned

   rtibblesbot

   on Jul 3, 2026
5. rtibblesbot commented on Jul 3, 2026

   

   rtibblesbot

   on Jul 3, 2026

   Contributor

   More actions

   Scoping notes before implementation

   Ran this through a spec pass since it touches two ambiguous-looking spots in the codebase. Posting the resolution here rather than asking, since the codebase itself settles both — flag if either read is wrong.

   QTI assessment-item type — constants.exercises gets QTI = "QTI", appended to question_choices. Uppercase is deliberate (breaks the file's existing lowercase-snake convention) because Studio's AssessmentItem.type choices are built directly from question_choices (contentcuration/models.py), and studio#5999 already fixes the literal as type='QTI'.

   Preset→bit ordering — format_presets.py currently has two orderings of the same preset set that have already drifted apart: the hand-written choices display tuple and PRESETLIST (sourced from resources/presetlookup.json, dict/JSON order). E.g. video_dependency/video_thumbnail/video_subtitle and audio_thumbnail/audio_dependency appear in different relative order between the two, and choices has a precedent for silently dropping an entry (VIDEO_VECTOR, commented out). tests/test_presets.py::test_format_presets_are_synced only checks the two share the same set of keys, never the same order — confirming choices' order was never meant to be significant.

   So the bit order is taken from PRESETLIST's existing order (i.e. presetlookup.json's), exposed as a small dedicated append-only id list (name TBD at implementation, e.g. RENDERABLE_PRESETS_ORDER) rather than a hand-maintained third ordering. Consumers compute 2 ** index themselves — le-utils only owns the order, mirroring the existing LEARNINGACTIVITIESLIST / Kolibri metadata-label-bitmask pattern this issue already points at (le-utils exposes the ordered list; kolibri/core/content/utils/search.py does the 2**j arithmetic). Not placed under constants/labels/ since that package is explicitly metadata-only and generated from specs — this is a functional preset concern, so it lives in format_presets.py next to PRESETLIST.

   Full writeup: .specs/2026-07-02-qti-preset-bitmask-design.md (local scratch, not committed).

   No open questions — ready for implementation.
6. rtibblesbot commented on Jul 3, 2026

   

   rtibblesbot

   on Jul 3, 2026

   Contributor

   More actions

   Plan: Add a QTI assessment-item type to constants.exercises and a stable, append-only preset→bit ordering list to constants.format_presets, so Studio and Kolibri can both import them for issue #224 (studio #1, studio #8, kolibri #10).

   • Add QTI assessment-item type
   • Add RENDERABLE_PRESETS_ORDER preset→bit ordering list

   ---

   @rtibblesbot's comments are generated by an LLM, and should be evaluated accordingly

   How was this generated?

   • Implemented code following the pre-approved plan using test-driven development (red-green-refactor)
   • Ran the project's full test suite and linter before committing
   • For UI changes: captured live screenshots to verify rendering
   • For backend changes: verified with example API/CLI output
7. rtibblesbot

   added a commit that references this issue on Jul 3, 2026

   feat: add QTI assessment-item type and renderable preset-bit ordering

   ...

   This issue will close once commit c1c7084 is merged into the 'main' branch.

   c1c7084
8. rtibbles

   closed this as completedin #229on Jul 3, 2026