Kopfdaten und Grenzen
- Release
- 7.0.3 → 7.0.4
- Commits
- 6
- Geänderte Dateien
- 12
- Analyse
- 11.08.2026
- Schwerpunkt
- Integritätsprüfung + Migrationsfix
Nicht untersucht
Verglichen wurden die Tags 7.0.3+260618 und 7.0.4+260620 mittels git log --oneline 7.0.3+260618..7.0.4+260620 und git diff --stat 7.0.3+260618..7.0.4+260620; beide Tags sind im Repository vorhanden. Nicht ausgewertet wurde der Commit „Dev Automatic translation update" und die davon betroffene Datei locale/_template/limesurvey.pot, weshalb keine Aussage darüber möglich ist, ob einzelne Oberflächentexte über die hier beschriebenen hinaus ihre Bedeutung geändert haben. Ebenfalls nicht ausgewertet wurden die minifizierten Stylesheets themes/admin/Sea_Green/css/sea_green.min.css und themes/admin/Sea_Green/css/sea_green-rtl.min.css, da sie aus den ebenfalls im Diff enthaltenen Quelldateien erzeugt werden. Die Laufzeitwirkung der neuen Integritätsprüfungen wurde nicht in einer Installation nachvollzogen, sondern ausschließlich aus dem Quellcode abgeleitet. Indirekte Effekte über transitive Drittabhängigkeiten sind durch reine Diff-Analyse nicht vollständig erfassbar. Einträge der Kurzliste mussten nicht ausgelassen werden.
Executive Summary
Dieses Release ist ein Wartungs-Release mit vier Commits an der Integritätsprüfung und einer Korrektur an der Migration von Version 6 auf Version 7. Die Integritätsprüfung findet nun deutlich mehr löschwürdige Datensätze als zuvor, und ihre Vorschläge werden bei Bestätigung ohne Rückfrage ausgeführt. Die eine Sache, die unbemerkt ungelöst bleibt: Die Migration der Ranking-Unterfragen wurde korrigiert, die interne Datenbank-Versionsnummer aber nicht angehoben — Installationen, die bereits auf 7.0.0 bis 7.0.3 migriert haben, führen die korrigierte Migration nicht erneut aus und behalten den falsch geschriebenen Fragetyp. Wer dagegen noch auf Version 6 steht, erhält mit diesem Release eine saubere Migration. Vor dem Ausführen der Integritätsprüfung ist ein Datenbank-Backup dringlicher als vor dem Update selbst.
- Migration der Ranking-Unterfragen korrigiert
- Integritätsprüfung entfernt typfremde Unterfragen und Antwortoptionen
- Integritätsprüfung erkennt verwaiste Archivtabellen der Fragen
- Archivnamen bei Deaktivierung zentral berechnet
Upgrade-Empfehlung
🧪 Vorher testen
Das Update selbst ändert weder Schema noch interne Datenbank-Versionsnummer und ist damit unkritisch. Die erweiterten Integritätsprüfungen können jedoch bei Bestätigung Unterfragen und Antwortoptionen auch aus aktiven Umfragen löschen, weshalb der Umfang der Vorschläge zunächst in einer Kopie der Produktivdatenbank geprüft werden sollte. Installationen, die noch von Version 6 migrieren, sollten dieses Release der Version 7.0.3 vorziehen.
Lesepfad
| Zielgruppe | Relevante Kennungen und Kapitel |
|---|---|
| Administratoren | A1, A2, A3, A4, Weitere relevante Änderungen, Empfehlung |
| Plugin-Entwickler | A4, Empfehlung |
| Theme-Entwickler | keine Kennung, Weitere relevante Änderungen, Empfehlung |
| Integratoren | A1, A2, Empfehlung |
| API-Nutzer | A1, Empfehlung |
Die wichtigsten Änderungen
A1: Migration der Ranking-Unterfragen korrigiert
Hintergrund — Mit Version 7 werden Ranking-Fragen nicht mehr über Antwortoptionen, sondern über Unterfragen abgebildet. Die Migration Update_700 erzeugt dafür aus jeder Antwortoption einer Ranking-Frage einen Datensatz in der Fragentabelle. Bisher wurde diesen erzeugten Unterfragen der Typ des langen Freitextes zugewiesen statt des Ranking-Typs. Zusätzlich fehlte eine Bereinigung: Waren an einer Ranking-Frage bereits Unterfragen vorhanden, konnten Alt- und Neubestand nebeneinander stehen. Beide Punkte werden nun in derselben Migration behoben, indem vorhandene Unterfragen von Ranking-Fragen zuerst gelöscht und die neuen anschließend mit dem korrekten Typ eingefügt werden.
Konsequenz — Wer noch auf einer Version 6 steht und direkt auf 7.0.4 aktualisiert, erhält Ranking-Unterfragen mit korrektem Typ. Für Installationen, die bereits auf 7.0.0 bis 7.0.3 migriert haben, greift die Korrektur nicht: Die interne Datenbank-Versionsnummer bleibt bei 708, die Migration Update_700 zielt auf Version 700 und wird deshalb nicht erneut ausgeführt. Diese Installationen behalten Unterfragen, deren Typspalte den Freitexttyp trägt, obwohl die übergeordnete Frage eine Ranking-Frage ist. Welche konkreten Folgen das für Anzeige, Export und ausgelesene Fragen-Eigenschaften hat, ist aus dem Diff nicht bestimmbar — die betroffenen Auswertungs- und Ausgabepfade sind in diesem Release nicht geändert worden. Ein Reparaturpfad für bereits migrierte Installationen ist im Diff nicht erkennbar. Das vorangestellte Löschen ist destruktiv: Es entfernt sämtliche vorhandenen Unterfragen aller Ranking-Fragen ohne Rücksicht darauf, ob sie aus einem Altbestand oder aus einer vorherigen Migration stammen; ob dabei zugehörige Übersetzungssätze mit entfernt werden, hängt von den Fremdschlüsseln der jeweiligen Datenbank ab und ist im Diff nicht belegt.
Vorher / Nachher
// Vorher (application/helpers/update/updates/Update_700.php)
INSERT INTO {{questions}}(parent_qid, sid, gid, type, title, question_order, relevance)
SELECT q.qid, q.sid, q.gid, '" . Question::QT_T_LONG_FREE_TEXT . "', a.code, a.sortorder, '1'
FROM {{answers}} a
JOIN {{questions}} q
ON a.qid = q.qid and q.type = '" . Question::QT_R_RANKING . "'
...
// Nachher
INSERT INTO {{questions}}(parent_qid, sid, gid, type, title, question_order, relevance)
SELECT q.qid, q.sid, q.gid, '" . Question::QT_R_RANKING . "', a.code, a.sortorder, '1'
FROM {{answers}} a
JOIN {{questions}} q
ON a.qid = q.qid and q.type = '" . Question::QT_R_RANKING . "'
...
// Neu (application/helpers/update/updates/Update_700.php)
public function deleteRankingSubquestions()
{
return "DELETE FROM {{questions}} WHERE parent_qid IN (SELECT qid FROM (SELECT qid FROM {{questions}} WHERE type = '" . Question::QT_R_RANKING . "' AND parent_qid = 0) AS rankingquestions)";
}
...
public function up()
{
$this->db->createCommand($this->deleteRankingSubquestions())->execute();
$this->db->createCommand($this->insertRankingSubquestions())->execute();
// Vorher (application/config/version.php)
$config['versionnumber'] = '7.0.3';
$config['dbversionnumber'] = 708;
...
$config['assetsversionnumber'] = '30491';
// Nachher
$config['versionnumber'] = '7.0.4';
$config['dbversionnumber'] = 708;
...
$config['assetsversionnumber'] = '30492';
Migrationsdetails — Die interne Datenbank-Versionsnummer bleibt vor und nach dem Update bei 708; das Update von 7.0.3 auf 7.0.4 führt also keine Migration aus, geändert wurde ausschließlich die bereits bestehende Migration Update_700 für Aufstiege von einer Version vor 7.0. Die Änderung ist rein datensatzbezogen ohne Strukturänderung: Die zitierten Anweisungen sind ein DELETE und ein INSERT auf die Fragentabelle, Definitionsanweisungen enthält das Zitat nicht. Idempotenz und Rückwärtskompatibilität sind nicht bestimmbar, da die Basisklasse der Migrationen ausschließlich eine up()-Methode als abstrakt vorschreibt und für Update_700 keine Gegenoperation vorhanden ist.
Nach dem Update testen — Auf einer Kopie einer Installation, die von Version 6 aufsteigt, nach der Migration die Typspalte der Unterfragen aller Ranking-Fragen prüfen und mit dem Typ der übergeordneten Frage vergleichen. Auf einer bereits auf 7.0.x migrierten Installation dieselbe Abfrage ausführen, um festzustellen, ob abweichend typisierte Unterfragen vorliegen, und anschließend eine betroffene Ranking-Frage im Fragebogen und im Datenexport gegenprüfen.
Betroffene Dateien — application/helpers/update/updates/Update_700.php, application/config/version.php, application/helpers/update/DatabaseUpdateBase.php
Relevante Commits — 2fd923ce58
A2: Integritätsprüfung entfernt typfremde Unterfragen und Antwortoptionen
Hintergrund — Die Integritätsprüfung im Administrationsbereich sammelt Datensätze, die aus Sicht des Datenmodells nicht mehr gültig sind, und löscht sie nach ausdrücklicher Bestätigung. Bislang prüfte sie Unterfragen und Antwortoptionen im Wesentlichen darauf, ob ein übergeordneter Datensatz existiert. Dieses Release ergänzt drei Kriterien: Unterfragen, deren übergeordnete Frage vollständig fehlt; Unterfragen, deren übergeordnete Frage einem Typ angehört, der keine Unterfragen zulässt; und Antwortoptionen, deren Frage einem Typ angehört, der keine Antwortoptionen zulässt. Welche Typen das jeweils sind, wird nicht fest hinterlegt, sondern zur Laufzeit aus den Typ-Eigenschaften abgeleitet.
Konsequenz — Wer die Integritätsprüfung nach dem Update aufruft, bekommt in aller Regel mehr Löschvorschläge angezeigt als zuvor. Besonders betroffen sind Installationen, die von Version 6 auf Version 7 migriert wurden, denn dort können an Ranking-Fragen zurückgebliebene Antwortoptionen liegen — der Ranking-Typ lässt in Version 7 Unterfragen, aber keine Antwortoptionen zu. Die Prüfung unterscheidet nicht zwischen aktiven und inaktiven Umfragen: Wird die Korrektur bestätigt, werden auch Unterfragen aktiver Umfragen gelöscht, deren Antwortspalten in der Antworttabelle bestehen bleiben und dann keinem Fragedatensatz mehr zugeordnet sind. Die Ausführung erfolgt nur über die ausdrückliche Bestätigungsaktion fixintegrity und nicht beim bloßen Anzeigen der Prüfung. Für Fragetypen, die nicht in der zentralen Typliste stehen, greifen die neuen Kriterien nicht, da unbekannte Typcodes in keiner der beiden abgeleiteten Listen landen.
Vorher / Nachher
// Neu (application/controllers/admin/CheckIntegrity.php)
$oCriteria = new CDbCriteria();
$oCriteria->join = 'LEFT JOIN {{questions}} parentq ON t.parent_qid = parentq.qid';
$oCriteria->condition = 't.parent_qid <> 0 AND parentq.qid IS NULL';
$orphanSubquestions = Question::model()->findAll($oCriteria);
foreach ($orphanSubquestions as $orphanSubquestion) {
$aDelete['questions'][] = array('qid' => $orphanSubquestion['qid'], 'reason' => gT('No parent question'));
}
// Neu (application/controllers/admin/CheckIntegrity.php)
$aTypesWithoutSubquestions = array();
$aTypesWithoutAnswers = array();
foreach (QuestionType::modelsAttributes() as $sTypeCode => $aTypeAttributes) {
if (empty($aTypeAttributes['subquestions'])) {
$aTypesWithoutSubquestions[] = $sTypeCode;
}
if (empty($aTypeAttributes['answerscales'])) {
$aTypesWithoutAnswers[] = $sTypeCode;
}
}
Nach dem Update testen — Die Integritätsprüfung zunächst auf einer Kopie der Produktivdatenbank aufrufen und die Liste der zur Löschung vorgeschlagenen Unterfragen und Antwortoptionen vollständig durchsehen, bevor die Korrektur in der Produktivumgebung bestätigt wird. Für jede vorgeschlagene Unterfrage prüfen, ob die zugehörige Umfrage aktiv ist, und in diesem Fall vor der Bestätigung einen Datenexport der Umfrage anlegen.
Betroffene Dateien — application/controllers/admin/CheckIntegrity.php, application/models/QuestionType.php
Relevante Commits — a787668830, 2fd923ce58
Sammel-Commit 2fd923ce580a71dcc50687154117169485cc38d9; umfasst die 2 vorstehenden Einträge.
A3: Integritätsprüfung erkennt verwaiste Archivtabellen der Fragen
Hintergrund — Beim Deaktivieren einer Umfrage wird die Antworttabelle in eine Archivtabelle umbenannt und zusätzlich ein Abzug der Fragendefinitionen als eigene Archivtabelle angelegt. Beide gehören zusammen und werden bei der Reaktivierung gemeinsam benötigt. Die Integritätsprüfung kannte bisher nur die Archive der Antworten, Zeitmessungen und Teilnehmerlisten; die Fragenarchive blieben unberücksichtigt und konnten unbemerkt zurückbleiben. Dieses Release ergänzt zwei Mechanismen: Die Prüfung sucht nun eigenständig nach Fragenarchiven, deren Umfrage nicht mehr existiert oder deren zugehöriges Antwortarchiv fehlt, und das Entfernen eines Antwortarchivs zieht das zugehörige Fragenarchiv mit.
Konsequenz — Administratoren finden in der Integritätsprüfung nun auch Fragenarchive in der Liste der verwaisten Tabellen und können sie über dieselbe Bestätigungsaktion entfernen. Beim Löschen alter Umfragedaten über die Redundanzbereinigung wird zusätzlich zu der ausgewählten Antwortarchivtabelle das gleichnamige Fragenarchiv gelöscht, ohne dass es in der Auswahlliste erscheint — die tatsächliche Löschmenge ist also größer als die angezeigte Auswahl. Der Abgleich erfolgt rein über den Tabellennamen: Nur Tabellen, deren Name nach Abzug des Tabellenpräfixes in mindestens vier durch Unterstrich getrennte Bestandteile zerfällt, werden überhaupt betrachtet. Für Installationen, deren Fragenarchive aus einer Zeit stammen, in der Antwort- und Fragenarchiv unterschiedliche Zeitstempel erhalten konnten, würde der Namensabgleich fehlschlagen und das Fragenarchiv als verwaist gelten; ob eine solche Konstellation in ausgelieferten Versionen tatsächlich entstehen konnte, ist aus dem Diff nicht bestimmbar.
Vorher / Nachher
// Neu (application/controllers/admin/CheckIntegrity.php)
$iQuestionsSID = $aTableParts[2];
$sDateTime = $aTableParts[3];
$sMatchingResponsesTable = $sDBPrefix . "old_responses_{$iQuestionsSID}_{$sDateTime}";
if (!in_array($iQuestionsSID, $aSIDs) || !in_array($sMatchingResponsesTable, $aResponsesTables)) {
$aDelete['orphansurveytables'][] = $sTableName;
}
// Neu (application/controllers/admin/CheckIntegrity.php)
if (tableExists($sQuestionsTableNameNoPrefix)) {
Yii::app()->db->createCommand()->dropTable($sQuestionsTableName);
$aData['messages'][] = sprintf(gT('Deleting related archived questions table: %s'), $sQuestionsTableName);
}
Nach dem Update testen — In der Datenbank die vorhandenen Fragenarchivtabellen auflisten, die Integritätsprüfung aufrufen und abgleichen, ob genau die Tabellen als verwaist gemeldet werden, deren Umfrage oder deren Antwortarchiv tatsächlich fehlt. Anschließend eine Umfrage deaktivieren, das entstandene Antwortarchiv über die Redundanzbereinigung löschen und prüfen, dass das zugehörige Fragenarchiv mit entfernt und in der Ergebnismeldung genannt wird.
Betroffene Dateien — application/controllers/admin/CheckIntegrity.php
Relevante Commits — 768972a16c
A4: Archivnamen bei Deaktivierung zentral berechnet
Hintergrund — Der Dienst, der eine Umfrage deaktiviert, benennt mehrere Tabellen in Archivtabellen um und legt zusätzlich das Fragenarchiv an. Bisher berechnete jede der beteiligten Methoden den gemeinsamen Namensbestandteil aus Umfrage-Kennung und Zeitstempel selbst, während der als Parameter durchgereichte reine Zeitstempel ungenutzt blieb. Der gemeinsame Namensbestandteil wird nun einmal in der aufrufenden Methode ermittelt und an die Teilmethoden übergeben; die Parameter dieser Methoden tragen entsprechend eine andere Bedeutung als zuvor.
Konsequenz — Für den Kernablauf ändert sich nichts Sichtbares. Die Methode, die den Namensbestandteil liefert, hält ihr Ergebnis je Umfrage-Kennung in einer Eigenschaft vor und gab deshalb schon zuvor innerhalb desselben Aufrufs denselben Wert zurück, sodass Antwort-, Zeit-, Teilnehmer- und Fragenarchiv bereits gleich benannt waren. Kein wörtliches Zitat verfügbar. Praktisch relevant ist die Änderung damit vor allem für Code, der von der Deaktivierungsklasse ableitet und eine der drei geschützten Methoden überschreibt: Der zweite Parameter enthält nun die Zeichenkette aus Umfrage-Kennung und Zeitstempel statt des reinen Zeitstempels. Eine Überschreibung, die daraus wie bisher selbst einen Tabellennamen zusammensetzt, erzeugt einen fehlerhaften Namen, ohne dass ein Typfehler auftritt — der Fehler zeigt sich erst an einer falsch benannten oder fehlenden Archivtabelle. Die Signaturen bleiben in Anzahl und Reihenfolge der Parameter unverändert, sodass es keinen Startfehler gibt.
Vorher / Nachher
// Vorher (application/models/services/SurveyDeactivate.php)
protected function handleSurveyTable($iSurveyID, $date, &$aData, $userID, $DBDate)
{
...
$siddate = $this->getSiddate($iSurveyID);
$sNewSurveyTableName = $this->app->db->tablePrefix . "old_responses_{$siddate}";
// Nachher
protected function handleSurveyTable($iSurveyID, $surveyDate, &$aData, $userID, $DBDate)
{
...
$sNewSurveyTableName = $this->app->db->tablePrefix . "old_responses_{$surveyDate}";
// Vorher (application/models/services/SurveyDeactivate.php)
$this->handleSurveyTable($iSurveyID, $date, $aData, $userID, $DBDate);
$this->handleTimingTable($iSurveyID, $date, $aData, $userID, $DBDate);
...
$siddate = $this->getSiddate($iSurveyID);
// Nachher
// Compute the archive suffix (<sid>_<timestamp>) once so every archived table shares the same date
$surveyDate = $this->getSiddate($iSurveyID);
...
$this->handleSurveyTable($iSurveyID, $surveyDate, $aData, $userID, $DBDate);
$this->handleTimingTable($iSurveyID, $surveyDate, $aData, $userID, $DBDate);
Nach dem Update testen — Eine Testumfrage mit Teilnehmerliste und aktivierter Zeitmessung deaktivieren und prüfen, dass Antwort-, Zeit-, Teilnehmer- und Fragenarchiv denselben Namenszusatz aus Umfrage-Kennung und Zeitstempel tragen. Eigene Ableitungen der Deaktivierungsklasse daraufhin durchsehen, ob sie eine der drei geschützten Methoden überschreiben, und die Bedeutung des zweiten Parameters dort anpassen.
Betroffene Dateien — application/models/services/SurveyDeactivate.php
Relevante Commits — 768972a16c
Sammel-Commit 768972a16c6ae2706597b0ec217eb651657a4e29; umfasst die 2 vorstehenden Einträge.
Weitere relevante Änderungen
Darstellung der Integritätsprüfungsseite korrigiert
Themes und Rendering · Kein Bruch · Theme-Entwickler, Administratoren
Eigene Anpassungen an dieser Seite müssen die geänderte Listenverschachtelung und die neue Ausrichtungsregel für die beiden Listenklassen im Sea-Green-Stylesheet berücksichtigen. (c8fc2484f7)
Assets-Versionsnummer angehoben
Themes und Rendering · Kein Bruch · Theme-Entwickler, Administratoren
Browser laden die Assets des Administrationsbereichs nach dem Update neu, weil assetsversionnumber von 30491 auf 30492 steigt. (fa2bb3a3d0)
Zuordnung nach Bereich
| Bereich | Vollständig beschrieben | Weitere Einträge |
|---|---|---|
| Sicherheit | keine | – |
| Datenbank | A1, A2, A3, A4 | – |
| RemoteControl API | keine | – |
| Survey Runtime | A1, A2 | – |
| Themes und Rendering | keine | ja |
| Plugin-Kompatibilität | A4 | – |
| Performance | keine | – |
Nicht betroffene Bereiche
Der Diff enthält keine Änderung an application/helpers/remotecontrol/remotecontrol_handle.php; die von der RemoteControl-Schnittstelle angebotenen Methoden und ihre Rückgabefelder sind damit im Diff unverändert.
Unterhalb von application/libraries/PluginManager/ zeigt der Diff keine Änderung; die Registrierung von Plugins und die Auslösung von Plugin-Events bleiben im Diff unberührt.
Unterhalb von themes/survey/ zeigt der Diff keine Änderung; das Twig-Markup und die Stylesheets der ausgelieferten Fragebogen-Themes sind im Diff unverändert. Die geänderten Stylesheets gehören zum Administrations-Theme unterhalb von themes/admin/Sea_Green/.
composer.json und composer.lock sind nicht Teil des Diffs; über Abhängigkeiten und Mindestversionen trifft dieses Release im Diff keine Aussage.
Das Verzeichnis application/helpers/update/updates/ enthält im Diff keine neue Migrationsklasse, und die interne Datenbank-Versionsnummer lautet im Zitat unter A1 vor und nach dem Update 708. Für das Update von 7.0.3 auf 7.0.4 sind damit im Diff keine Schema-, Spalten-, Index- oder Constraint-Änderungen erkennbar.
Empfehlung
Administratoren
Vor dem Update — Ein vollständiges Datenbank-Backup anlegen, auch wenn das Update selbst keine Migration ausführt; das Backup wird für die anschließende Integritätsprüfung gebraucht (A2, A3). Feststellen, ob die Installation bereits auf 7.0.x migriert wurde oder noch von einer Version vor 7.0 aufsteigt, denn nur im zweiten Fall greift die Korrektur der Ranking-Migration (A1). Bei einem Aufstieg von Version 6 die Migration zunächst auf einer Kopie der Produktivdatenbank durchführen und die Typspalte der Ranking-Unterfragen prüfen (A1).
Unmittelbar nach dem Update — Die Integritätsprüfung zuerst in einer Testumgebung aufrufen und die Liste der Löschvorschläge vollständig durchsehen, bevor sie in der Produktivumgebung bestätigt wird (A2). Vor der Redundanzbereinigung berücksichtigen, dass zu jedem ausgewählten Antwortarchiv zusätzlich das zugehörige Fragenarchiv gelöscht wird (A3). Eine Testumfrage deaktivieren und die einheitliche Benennung der Archivtabellen kontrollieren (A4).
Rollback — Ein Rückschritt von 7.0.4 auf 7.0.3 erfordert nach Ausweis des Zitats unter A1 keinen Eingriff in die Datenbank, da die interne Datenbank-Versionsnummer vor und nach dem Update 708 lautet und das Release keine Migration ausführt; ein Zurückspielen des Dateistands genügt. Wurde dagegen mit diesem Release von einer Version vor 7.0 aufgestiegen, ist ein Rollback der Migration nicht ohne Weiteres möglich: Für Update_700 ist keine Gegenoperation vorhanden, und das vorangestellte Löschen der Ranking-Unterfragen ist destruktiv — hier hilft ausschließlich das Einspielen des Backups. Wurden Löschvorschläge der Integritätsprüfung bestätigt, sind die entfernten Unterfragen, Antwortoptionen und Archivtabellen ebenfalls nur aus dem Backup wiederherstellbar; die Rückwärtskompatibilität dieser Löschungen ist nicht bestimmbar und sollte vorab in einer Testumgebung geprüft werden.
Plugin-Entwickler
Eigene Klassen daraufhin durchsehen, ob sie von der Deaktivierungsklasse ableiten und eine ihrer geschützten Methoden für Antwort-, Zeit- oder Teilnehmerarchiv überschreiben; der zweite Parameter enthält nun die Zeichenkette aus Umfrage-Kennung und Zeitstempel und darf nicht mehr um die Umfrage-Kennung ergänzt werden (A4). Anschließend eine Deaktivierung mit aktivem Plugin durchführen und die Namen der entstandenen Archivtabellen kontrollieren (A4).
Theme-Entwickler
Keine vollständig beschriebene Änderung betrifft diese Gruppe. Zwei Einträge unter Weitere relevante Änderungen sind dennoch zu beachten: Anpassungen am Administrations-Theme, die auf die Listenstruktur der Integritätsprüfungsseite oder auf deren Stylesheet-Regeln aufsetzen, sind gegen den neuen Stand zu prüfen, und die angehobene Assets-Versionsnummer erzwingt ein Neuladen der Assets im Administrationsbereich.
Integratoren
Vor der Bestätigung der Integritätsprüfung erheben, ob nachgelagerte Systeme auf Unterfragen oder Antwortoptionen zugreifen, die von den neuen Kriterien erfasst werden, insbesondere auf Antwortoptionen von Ranking-Fragen (A2). Bei Installationen, die von einer Version vor 7.0 aufsteigen, die Typspalte der Ranking-Unterfragen in die Abnahme aufnehmen (A1); bei bereits auf 7.0.x migrierten Installationen prüfen, ob dort abweichend typisierte Unterfragen vorliegen, da die Korrektur für sie nicht greift (A1).
API-Nutzer
Auf Installationen, die von einer Version vor 7.0 aufsteigen, nach der Migration die über die Schnittstelle ausgelesenen Eigenschaften einer Ranking-Frage und ihrer Unterfragen mit dem Stand vor dem Aufstieg vergleichen, da der geschriebene Fragetyp sich geändert hat (A1). Auf bereits migrierten Installationen dieselbe Abfrage ausführen, um festzustellen, ob dort noch der abweichende Typ ausgeliefert wird (A1).