-- Migration 017: Eine bestaetigte Nachpruefung wird im Datenbestand sichtbar
--
-- Additive Migration. Der Migrator toleriert 1050/1060/1061/1062/1091.
--
-- WOZU
--
-- Der Unterschied zwischen "ich habe es behoben" und "der Fix eines anderen
-- traegt" ist das Rueckgrat des Pruefverfahrens aus Migration 015. Er stand
-- bisher nur in der Anleitung. Im Datenbestand kam beides als status='closed'
-- an - `dc-testkit confirm` setzte den Status und schrieb den Rest in einen
-- Kommentar.
--
-- Damit war die eine Frage, fuer die das ganze Verfahren gebaut ist, nicht
-- beantwortbar: Wurde dieses Item gegen ein ausgeliefertes Paket geprueft -
-- oder hat jemand es zugemacht? Ein Kommentartext ist keine Antwort darauf;
-- er laesst sich nicht zaehlen, nicht filtern und nicht auswerten.
--
-- Drei Spalten, die genau das festhalten:
--
--   verified_at        wann bestaetigt
--   verified_in_build  gegen welche Fassung geprueft wurde
--   verified_by        wer geprueft hat
--
-- WARUM NICHT EIN EIGENER STATUS
--
-- Ein Status "verified" neben "closed" waere ein zweites Kennzeichen fuer
-- dieselbe Sache - dieselbe Falle, die Migration 016 beim is_roadmap-Flag
-- vermieden hat. Ein bestaetigtes Item IST geschlossen; die Bestaetigung ist
-- eine Eigenschaft dieses Abschlusses, kein anderer Zustand. Jede Auswertung
-- ueber offene und geschlossene Items bliebe sonst richtig nur, solange sie
-- an beide Werte denkt.
--
-- WARUM verified_in_build NEBEN resolved_in_build
--
-- Sie beantworten verschiedene Fragen und koennen auseinandergehen - genau
-- das ist der interessante Fall. resolved_in_build ist eine Behauptung des
-- Behebenden ("ab 1.4.3 ist es weg"), verified_in_build die Beobachtung des
-- Pruefenden ("in 1.4.5 nicht mehr aufgetreten"). Stimmen sie ueberein, wurde
-- gegen genau den angekuendigten Build geprueft. Weicht der gepruefte ab, ist
-- die Aussage schwaecher, und man sieht es.
--
-- WARUM KEIN verified_from FUER DAS PRUEFENDE PROJEKT
--
-- Das steht schon in verified_by: Der Akteur wird serverseitig aus dem Token
-- abgeleitet und nicht aus dem Rumpf uebernommen (wie created_by). Ein
-- zweites Feld dafuer waere eine zweite Wahrheit.

ALTER TABLE bugtracker_items
  ADD COLUMN verified_at DATETIME NULL AFTER resolved_at;

ALTER TABLE bugtracker_items
  ADD COLUMN verified_in_build VARCHAR(64) NULL AFTER verified_at;

ALTER TABLE bugtracker_items
  ADD COLUMN verified_by VARCHAR(190) NULL AFTER verified_in_build;

-- Auswertung "was wurde in Fassung X bestaetigt" und "was ist geschlossen,
-- ohne je geprueft worden zu sein". Die zweite Frage ist die wichtigere: Sie
-- misst, wie belastbar die Zahl der geschlossenen Items ueberhaupt ist.
ALTER TABLE bugtracker_items
  ADD KEY ix_bt_verified (verified_at, verified_in_build);