Schemer: (Re)aktivieren von Basisvariablen führt zu Dopplungen

[schumaki]

Beschreibung

Auf dem Bio-Board gibt es Aufgaben, bei denen die Items in der Kodierungsspalte nicht angezeigt werden. Vermutlich wurden die Basisvariablen von den AEs aus Versehen aus der Kodierungsspalte entfernt.
Wenn ich die Variablen wieder aktiviere (im Bsp. Var 01) kommt ein Fehlerdialog:

Nach dem automatischen Auflösen sieht erstmal alles gut aus:

Wenn ich den Kodierungstab verlasse und neu lade, sind jedoch deutlich mehr Variablen hinzugekommen und rot markiert:

Interessanter Weise ist gerade die durch Auflösung erstellt Variable 01_1 verschwunden

Erwartetes Verhalten

• Versehentlich deaktivierte Basisvariablen sollten (z. B. über "Basisvariable ohne Wert aktivieren") wiederhergstellt werden können.
• Die Funktion Doppelte Variablen-IDs/Aliase auflösen sollte nochmal gründlich auf unerwartete Nebeneffekte (Erzeugen neuer Variablen, Anzeigen von weiteren Konflikten, die nicht durch die aktuelle Aktion entstanden sind, Änderungen die erst nach neu laden des Kodierungstabs angezeigt werden, etc.) getestet werden

Reproduktionsschritte

1. Kopie von https://www.iqb-studio.de/#/a/1018/137933/preview erstellen
2. Zum Kodierungstab navigieren
3. Burgermenü -> "Basisvariable ohne Wert aktivieren"
4. 01 aktivieren
5. Bei Doppelte Variablen-IDs/Aliase auflösen beobachten, welche Variablen neben 01 noch als Konflikt angezeigt werden
6. Auto-Fix verwenden
7. Beobachten, welche Variablen neu erstellt werden
8. In einen andern Tab und dann zurück zu Kodierung wechseln
9. Beobachten,

• welche Variablen aus 7. noch vorhanden sind,
• welche Variablen nun neu hinzugekommen sind und
• welche Variablen doppelt vorhanden sind

Beispiele

• BiSta NaWi Biologie: https://www.iqb-studio.de/#/a/1018/137933/preview

---

Versionen

• Schemer 2.6.1 (scheint aber auch unter 2.7.0 aufzutreten), Aspect 2.11.6
• Betriebssystem: Win 11
• Browser: Firefox

[jurei733]

Kurze Einschätzung nach Code-Lektüre: Das sieht nach einem echten Synchronisationsproblem zwischen varList und codingScheme.variableCodings aus, nicht nur nach einem Darstellungsfehler.

Plausibler Ablauf:

• Beim Reaktivieren einer BASE_NO_VALUE-Variable wird sie wieder auf BASE gesetzt und zusätzlich direkt in die aktuelle varList gepusht.
• Wenn die Variable dort schon aus der Unit-/Item-Definition vorhanden ist oder beim Tab-Neuladen wieder aus der externen Quelle kommt, entsteht eine doppelte ID/Alias-Situation.
• Der Auto-Fix arbeitet dann global auf der varList und kann IDs wie 01_1 erzeugen. Diese Änderung ist aber nicht die eigentliche Quelle der varList.
• Nach dem Wechseln/Neuladen wird die varList neu aufgebaut, wodurch die Auto-Fix-Variante wieder verschwinden kann, während Änderungen an codingScheme.variableCodings erhalten bleiben. Dadurch entstehen anschließend zusätzliche BASE-Variablen bzw. rote Konflikte.

Ich würde den Fix daher nicht primär im Dialog selbst suchen, sondern im Abgleich:

1. activateBaseNoValueVars() sollte keine zweite varList-Zeile erzeugen, wenn ID/Alias bereits vorhanden ist.
2. updateVariableLists() sollte varList-Einträge nach ID deduplizieren und BASE-Codings anhand ID/Alias sauber reconciliieren, statt bei Reload neue BASE-Variablen nachzuziehen.
3. Der Duplikat-Dialog sollte beim Auto-Fix IDs aus der aktuellen varList nicht fälschlich als reservierte Fremd-IDs behandeln.
4. idRenameMap sollte bei ursprünglich doppelten IDs nicht pauschal auf codingScheme.variableCodings angewendet werden, weil die Zuordnung dann mehrdeutig ist.

Als Regressionstest wäre genau der beschriebene Fall sinnvoll: 01 reaktivieren, ggf. Auto-Fix ausführen, Tab wechseln/zurück, danach darf weiterhin nur eine BASE-Variable für 01 existieren und keine erzeugte _1/_2-Variable übrig bleiben.

[schumaki]

Jessica C., 13.05.:
Bei genauerer Überlegung denke ich, dass es am besten wäre, wenn man die Basisvariablen nicht im Kodierreiter löschen kann, solange die Elemente noch im Editor vorhanden sind. Leider haben wir dieses Problem nämlich immer wieder, dass die Aufgabenentwickler*innen wild im Kodierungsreiter rumlöschen und wir dann vor der Aufgabe stehen, das entweder wiederherzustellen oder die Aufgabe komplett nachzubauen. Angesichts unseres ohnehin straffen Zeitplans ist das ein Problem. Vielleicht findet man ja eine technische Lösung, um die Kodierung zu schützen.