Zum Inhalt springen

Löschen: die Handlung, die vorher am meisten erklären muss

Version 0.4.04 Min. Lesezeit

Gelöscht wurde in GODAV Pro schon lange, nur nicht in der Oberfläche. Die Schnittstellen dafür gab es seit den ersten Tagen. Gefehlt hat der Knopf, und vor allem die Rückfrage, die vorher sagt, was passiert. Bei einem Epic mit dreißig Aufgaben darunter, einem Projekt mit zweihundert Vorgängen oder dem Konto einer Kollegin ist genau diese Rückfrage der eigentliche Teil der Arbeit. Gelöscht wird dabei immer weich: Die Zeilen bleiben in der Datenbank und werden nur als gelöscht markiert, damit Kommentare, Buchungen und Protokolleinträge ihre Bezüge behalten.

Vorgänge: die richtige Zahl

„Löschen“ steht als letzter Eintrag im Menü „Aktionen“ der Vorgangskarte. Die Rückfrage nennt, wie viele Vorgänge darunter hängen und welcher Art sie sind.

Die Rückfrage „Vorgang löschen“ für ein Feature mit zehn untergeordneten Vorgängen Zehn Vorgänge gehen mit, aufgeschlüsselt nach Art. Der Hinweis zu den Zeitbuchungen kam etwas später dazu.

Die Zahl sieht einfach aus und hatte eine Falle. Es gab bereits eine Abfrage für die Kinder eines Vorgangs, und die hätte ich mitbenutzen können. Sie kennt aber nur eine Ebene. Ein Epic mit drei Features und dreißig Aufgaben hätte „3“ gemeldet und 33 gelöscht. Deshalb rechnet der Server die Vorschau über den ganzen Teilbaum, mit derselben Rechnung, die danach auch löscht.

Geprüft wird das Löschrecht für jede Vorgangsart, die im Teilbaum tatsächlich vorkommt. Wer Features löschen darf, aber keine Aufgaben, kann ein Feature mit Aufgaben nicht löschen. Die Maske sagt dann, welche Rechte fehlen, und zwar alle auf einmal. Die erste Fassung brach beim ersten fehlenden Recht ab, und wer zwei nicht hatte, erfuhr das in zwei Anläufen.

Die untergeordneten Vorgänge selbst sperren dagegen nichts. Beim Umwandeln macht ein Kind die Handlung unmöglich, beim Löschen ist es nur der Anlass, genauer nachzufragen.

Gebuchte Zeit bleibt gebucht

Eine Regel habe ich erst nachträglich so entschieden, sie gehört aber hierher: Die Zeitbuchungen eines gelöschten Vorgangs zählen weiter. Gearbeitet wurde ja trotzdem. Vorher blieben die Buchungen zwar in der Datenbank, verschwanden aber aus jeder Ansicht, und damit sank rückwirkend die Tagessumme, ein längst erledigter Tag galt wieder als offen, und die Auslastung im Bericht fiel. Heute steht der Vorgang in der Tagesliste grau mit „(gelöscht)“, und die Stunden zählen mit. Läuft am Vorgang gerade eine Stoppuhr, auch die von jemand anderem, wird sie beim Löschen angehalten und gebucht. Später ließe sie sich nur noch verwerfen, und die Zeit wäre weg.

Projekte: Löschen ist nicht Deaktivieren

Auf der Projektkarte liegen „Deaktivieren“ und „Löschen“ im selben Menü, mit zwei getrennten Rechten. Ich hätte Löschen erst nach dem Deaktivieren erlauben können, als zusätzliche Sicherung. Das wäre aber eine Regel gewesen, die nur in der Oberfläche steht und die der Server nicht kennt, also mit dem ersten anderen Aufrufer wirkungslos. Stattdessen nennt die Rückfrage den milderen Weg im Text.

Die Rückfrage „Projekt löschen?“ mit der Zahl der Vorgänge und dem Hinweis auf das Deaktivieren Die Zahl der Vorgänge stand ohnehin schon auf der Karte, deshalb braucht das Projekt keine eigene Vorschau vom Server.

Konten: gezählt wird, was bleibt

Beim Benutzerkonto ist die Rückfrage umgedreht. Fast nichts verschwindet: Kommentare, Zeitbuchungen und Protokolleinträge bleiben unter dem Namen der Person stehen. Weg fallen nur Aussagen über die Gegenwart, also Mitgliedschaften, Zuweisungen und Projektleitungen.

Die Rückfrage „Konto löschen?“ mit dem, was bleibt, und dem, was entfällt Heutiger Stand: Was entfällt, kommt bei einer Wiederherstellung inzwischen zurück. Mailadressen sind unkenntlich gemacht.

Was bleibt, entscheidet die Bedeutung und nicht die Technik. Die Datenbank hat für einige Bezüge die Regel „beim Löschen leeren“ hinterlegt, etwa für den Erfasser eines Vorgangs. Diese Regel ist aber für das harte Löschen gedacht, bei dem die Zeile wirklich verschwindet. Beim weichen Löschen gibt es keinen Grund dafür: Wer einen Vorgang erfasst hat, hat ihn erfasst.

Zwei Folgen nehme ich bewusst in Kauf. Ein Projekt kann leer werden, wenn sein letztes Mitglied gelöscht wird. Die Alternative wäre, dass das Löschen eines Kontos an einem Projekt scheitert, das der Administrator gar nicht im Blick hat. Und die Anmeldeadresse wird wieder frei: Wird derselbe Mensch neu angelegt, ist das ein neues Konto. Die Rückfrage sagt beides. Sie sagt auch, was das Löschen nicht ist, nämlich eine Anonymisierung, denn der Name steht weiter in jedem alten Kommentar.

Außerdem

  • Gelöscht wird nur von der Karte aus, nie aus einer Liste. Ein Papierkorb mitten in einer Tabelle wäre verstecktes Bearbeiten, und die Rückfrage braucht Platz für ihre Zahlen.
  • Das eigene Konto und der letzte aktive Administrator lassen sich nicht löschen, und der Knopf sagt das, statt zu verschwinden.

Einen Weg zurück gab es zu diesem Zeitpunkt nur über die Datenbank. Wie gelöschte Elemente wieder in die Oberfläche kommen, ist ein eigenes Thema und kam etwas später.

  • Vorgänge
  • Administration
  • Datenschutz