Skip to content

Startwert der Qualitätsprüfung: 0 % statt 7 % (v2.41.1) - #121

Merged
daimpad merged 1 commit into
mainfrom
claude/fix-data-prep-errors-kJYpl
Aug 27, 2026
Merged

Startwert der Qualitätsprüfung: 0 % statt 7 % (v2.41.1)#121
daimpad merged 1 commit into
mainfrom
claude/fix-data-prep-errors-kJYpl

Conversation

@daimpad

@daimpad daimpad commented Aug 27, 2026

Copy link
Copy Markdown
Owner

Beim Klick auf „Neuen Datensatz anlegen" stand die Qualitätsprüfung nicht bei 0 %, sondern bei 7 % — bevor irgendjemand etwas eingetragen hatte.

Ursache

Zwei Quellen, beide dieselbe Sorte Fehler: Der Wizard rechnete sich an, was er selbst vorgibt.

Metrik Punkte Woher
modified 5 WordPress legt beim Öffnen des Formulars einen Auto-Entwurf an und feuert dabei save_post; set_modified_date() stempelte das Änderungsdatum.
access_rights 10 Carbon Fields liefert für ungespeicherte Felder ihren Vorgabewert zurück — die Zugriffsrechte stehen auf „öffentlich".
access_rights_vocab 5 Derselbe Vorgabewert, als Vokabulartreffer nochmals gezählt.
Summe 20 von 295 bewertbaren Punkten = 7 %

Nachgestellt mit einem Wegwerf-Skript gegen ODW_Quality::calculate(): draft 20 / 295 = 7 %, auto-draft 0 / 295 = 0 % nach der Korrektur.

Änderung

  • ODW_Quality::evaluate_metric() wertet auf einem Auto-Entwurf nichts als erfüllt. Der Nenner bleibt dabei stehen — die Metriken sind prüfbar, sie sind nur noch nicht erfüllt. Wären sie „nicht bewertbar", ergäbe 0 von 0 Punkten wieder eine Zahl, die niemand erwartet.
  • ODW_Fields::set_modified_date() überspringt Auto-Entwürfe. Auf einen Datensatz, den niemand gespeichert hat, gehört kein dct:modified — es datierte ihn auf das Aufrufen des Formulars.
  • Erklärtext im Bericht neu formuliert. Er behauptete, ein leerer Datensatz stehe nie bei 0 % — das stimmt jetzt nicht mehr, und die 15 Punkte aus den vorbelegten Feldern unterschlug er ohnehin.

Was bleibt

Nach dem ersten Speichern eines leeren Entwurfs steht der Wert wieder bei 7 %: Dann ist das Änderungsdatum real gesetzt und die Zugriffsrechte sind als „öffentlich" gespeichert — beides steht dann tatsächlich in den Metadaten, und MQA würde es genauso zählen. Der Erklärtext sagt das jetzt. Falls der vorbelegte Zugriffsrechte-Wert auch dort nicht mitzählen soll, ist das eine eigene Entscheidung — sag Bescheid.

Geprüft

267 Tests grün (2 neue) · PHPCS ohne Befund · bin/verify-package.py und bin/check-i18n.py sauber.

Neue Tests:

  • derselbe Meta-Wert zählt im Entwurf, nicht im Auto-Entwurf
  • calculate() ergibt 0 bei stehendem Nenner — die Mocks liefern absichtlich für jedes Feld einen gefüllten Wert, der Test hält also nicht bloß fest, dass ein leeres Formular 0 ergibt
  • E2E: das frisch geöffnete Formular zeigt 0 %

Version 2.41.0 → 2.41.1.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq


Generated by Claude Code

Zwei Ursachen, beide dieselbe Sorte Fehler: Der Wizard rechnete sich an,
was er selbst vorgibt.

WordPress legt beim Öffnen des Formulars einen Auto-Entwurf an und feuert
dabei save_post. set_modified_date() stempelte daraufhin das
Änderungsdatum, obwohl niemand etwas gespeichert hatte — 5 Punkte. Und
Carbon Fields liefert für ungespeicherte Felder ihren Vorgabewert zurück:
Die Zugriffsrechte stehen auf „öffentlich", das zählte als Angabe plus
Vokabulartreffer — 10 + 5 Punkte. Zusammen 20 von 295 bewertbaren
Punkten, also die gemeldeten 7 %.

Der Bericht wertet auf einem Auto-Entwurf jetzt nichts als erfüllt, und
set_modified_date() überspringt ihn (auf einen Auto-Entwurf gehört kein
dct:modified — es datierte den Datensatz auf das Aufrufen des Formulars).

Der Nenner bleibt stehen: Die Metriken sind prüfbar, sie sind nur noch
nicht erfüllt. Wären sie „nicht bewertbar", ergäbe 0 von 0 Punkten wieder
eine Zahl, die niemand erwartet.

Der Erklärtext im Bericht behauptete bisher, ein leerer Datensatz stehe
deshalb nie bei 0 % — das stimmt jetzt nicht mehr und unterschlug
außerdem die 15 Punkte aus den vorbelegten Feldern. Neu formuliert.

Tests: zwei Unit-Tests (derselbe Meta-Wert zählt im Entwurf, nicht im
Auto-Entwurf; calculate() ergibt 0 bei stehendem Nenner) und ein
E2E-Test auf die 0 % im frisch geöffneten Formular.

https://claude.ai/code/session_01JB1xUQM892bVZ4Yv3MZjvq
@daimpad
daimpad merged commit 9cbe6cb into main Aug 27, 2026
22 checks passed
@daimpad
daimpad deleted the claude/fix-data-prep-errors-kJYpl branch August 27, 2026 12:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants