Question type conversion

[AlexVelezLl]

Summary

Changing a question's type used to keep only the question and drop the answers without warning. Now the conversion keeps everything the new type can hold. When the change would also remove something, or change what counts as correct in a way validation can't catch, the editor first asks for confirmation in a modal that lists each change in one sentence. A change that loses nothing switches straight away.

• Answers carry over within three families of question types. Across families, only the question carries over.
  • Answer lists (single, multi, numeric, text entry, free response, ordering): answers, which ones are correct, shuffle, fixed answers, orientation and expected length.
  • Pairs (associate ↔ match): pairs and distractors. Going to match, pairs that share a source become one row with several matches, the way match shows them.
  • Passages (inline choice; gap match in [QTI] Gap match interaction: descriptor, parsing, XML assembly and validation #6203): converting an inline choice question to any other type folds its passage into the question, with each dropdown shown as _____, since the question field above it is optional.
• Anything the new type can show is kept, even if it isn't valid there, and validation points it out. For example, answers that aren't numbers are kept when switching to numeric. Numeric answers going to another type are written the way the exercise language shows them (3,5 in a German exercise), since that's what the author sees in the numeric editor. The exception is single choice, which keeps only its first correct answer marked, because radio buttons can't show more than one.
• Every type change remounts the editor from the converted question. As a result, a free response really clears its answers.
• Focus stays on the type selector through a type change, with or without the modal, and cancelling lets the author pick the same type again.
• Editors no longer focus their question by themselves when they mount, which is what used to pull focus away after a type change. The card now asks for it through a focus() method on each editor, when it opens or when a new question is added. TipTapEditor now also focuses once it's ready when it was switched into edit mode before then; without that, a new question's editor would have opened its question without focusing it.

Conversion rules

Each cell lists what the modal says when converting a filled question from the row's type to the column's type. "—" means nothing is lost, so there's no modal. A sentence only shows when it applies to the question's actual content. For example, "Answers not marked as correct will be removed" only shows if there is a non-empty answer that isn't marked correct.

From \ To	Single	Multi	Numeric	Text entry	Free resp.	Ordering	Associate	Match	Inline choice
Single		—	I	I	A	C, O	A	A	A
Multi	R		I	I	A	C, O	A	A	A
Numeric	R	—		—	A	O	A	A	A
Text entry	R	—	—		A	O	A	A	A
Free response	—	—	—	—		—	—	—	—
Ordering	N	N	A	A	A		A	A	A
Associate	A	A	A	A	A	A		—	A
Match	A	A	A	A	A	A	—		A
Inline choice	P	P	P	P	P	P	P	P

• A: All answers will be removed.
• I: Answers not marked as correct will be removed. (Only the correct choices become accepted answers; a wrong choice would otherwise become an accepted one.)
• R: Only the first correct answer will stay marked as correct.
• C: Answers will no longer be marked as correct.
• O: The current order will become the correct order. (With more than one answer.)
• N: The correct order won't be kept. (With more than one answer.)
• P: The passage will be added to the question, with each blank shown as "_____". Its answers will be removed.
• F: Formatting, images and formulas in answers will be removed. (Not shown in the table: added whenever rich answers, from single, multi or ordering, go into numeric or text entry and lose something.)

Where this differs from the old editor's conversion:

• Answers that aren't numbers are kept when switching to numeric, and validation flags them.
• Wrong choices are dropped when switching to numeric or text entry, instead of becoming accepted answers.
• Converting to single choice never marks an answer correct that the author didn't mark.
• An inline choice passage is folded into the question.
• Numeric answers going to another type keep the exercise language's decimal separator.

The rules live in one table in conversion/answerKeys.js. EXPECTED_LOSSES in conversion/__tests__/convertInteraction.spec.js checks the table above for every pair.

References

Closes #6190. Gap match (#6202) only needs its own export and import (#6203) to convert to and from inline choice.

Reviewer guidance

• Ten commits, each reviewable on its own:
  1. Upgrade KDS to 5.10.0, for KSelect's public focus() (KSelect: Add a public focus() method kolibri-design-system#1354), which keeps focus on the type selector
  2. The conversion core: the rules table, passage folding, and the descriptor defaults
  3. Answer-list types
  4. Associate ↔ match
  5. Inline choice passages
  6. The modal
  7. Editors focus their question only when the card asks, through focus() (includes the TipTapEditor fix)
  8. Wiring the conversion into InteractionSection. The remount replaces Read and show Numeric answers in the exercise language #6282's questionType watch in useTextEntryInteraction, so that watch is removed and its tests moved to InteractionSection.spec.
  9. A test that every interaction exports all of its content
  10. Numeric answers converted to other types use the exercise language's decimal separator. Read and show Numeric answers in the exercise language #6282 left them as stored; this changes that, so it's worth a look from Read and show Numeric answers in the exercise language #6282's author.
• To try it: open an exercise and fill in a question. Then switch its type and check that each modal lists what the table says. For example, single → multi (no modal), single → text entry (I), multi → single (R), choice → ordering (C, O), and anything → free response (A). Then cancel, pick the same type again, and confirm, with the mouse and with the keyboard only.
• Inline choice: its editor (Add the inline choice interaction editor #6303) isn't on unstable yet. Converting from inline choice is covered by tests here, and authors get it once Add the inline choice interaction editor #6303 merges. Its editor will also need a focus(); the registry test in step 7 will fail until it has one.
• Passage-to-passage conversion has no caller yet: inline choice's import side (importInlineChoiceContent, buildDropdown) and carryPassage only run when a passage goes into another passage type, and inline choice is the only one until gap match ([QTI] Gap match interaction: descriptor, parsing, XML assembly and validation #6203). They're exercised by tests only for now, kept so every family uses the same mechanism and gap match only adds its own export and import.
• The conversion/ folder sits beside interactions/ rather than inside it, since every folder in interactions/ is a plugin.
• Checked in a browser (Chrome via Playwright, dev server):
  • after a switch with no modal, a cancel, or a confirm, focus is on the type selector, for every question type
  • opening a card, or adding a new question, focuses its question, for every question type
  • the keyboard alone can open the select, pick a type, cancel with Escape, Tab to Change and confirm
  • a confirmed conversion is saved to the server
  • with the modal open, axe reports nothing new (only the edit window's existing close button, and button text contrast)

Modal, confirm and cancel:

Keyboard only:

AI usage

Claude Code researched the options, wrote the plan with me, implemented it with tests, self-reviewed it, and addressed my review. I made the conversion decisions (which answers carry over, when to warn, folding the passage) and reviewed the changes.

🤖 Generated with Claude Code