Bug #336

Nachträgliche Logstatusänderung wirkungslos

Von mic@ vor mehr als 4 Jahren hinzugefügt. Vor etwa 2 Jahren aktualisiert.

Status:erledigt% erledigt:

100%

Priorität:3 hoch
Zugewiesen an:following
Zielversion:Version 18
Ticket Referenz: Kategorien:logs

Beschreibung

Folgendes Szenario konnte ich nachstellen:
Wenn ein Listing deaktiviert wurde, man danach ein Log vom Typ "Bemerkung" schreibt
und dann im nachhinein dieses Log auf den Status "Kann gesucht werden" umsetzt,
dann bleibt das Listing trotzdem deaktiviert.


Zugehörige Tickets

Beziehung mit OC Entwicklung - Change #231: Mini-Feature Statuslogs sollten nicht mehr editierbar sein verworfen
Beziehung mit OC Entwicklung - Change #709: Wartungslog besser benennen offen
Dupliziert durch OC Entwicklung - Bug #708: Nachträgliche Deaktivierung erfolglos abgewiesen
Dupliziert durch OC Entwicklung - Bug #862: Deaktivierungs-Log ohne Deaktivierung?! abgewiesen

Zugehörige Revisionen

Revision 22e45486
Von following vor etwa 2 Jahren hinzugefügt

improved handling of log type changes; updates #336

Revision 12c8a0ce
Von following vor etwa 2 Jahren hinzugefügt

improved handling of log type changes; updates #336

Historie

#1 Von Schrottie vor mehr als 4 Jahren aktualisiert

mic@ schrieb:

Folgendes Szenario konnte ich nachstellen:
Wenn ein Listing deaktiviert wurde, man danach ein Log vom Typ "Bemerkung" schreibt
und dann im nachhinein dieses Log auf den Status "Kann gesucht werden" umsetzt,
dann bleibt das Listing trotzdem deaktiviert.

Ich würde das eher als Feature sehen, denn diese Vorgehensweise würde Watchmails aushebeln. So wie es jetzt ist, ist man gezwungen ein komplett neues "Enable-Log" zu schreiben, das auch per Mail an potenzielle Watcher rausgeht. Zu überlegen wäre also eher, ob man nicht in der "editlog.php" die entsprechenden Logtype "Archivierung, Deaktivierung, Aktivierung" einfach sperrt und damit generell ein neues Log forciert.

#2 Von Slini11 vor mehr als 4 Jahren aktualisiert

Schrottie schrieb:

Zu überlegen wäre also eher, ob man nicht in der "editlog.php" die entsprechenden Logtype "Archivierung, Deaktivierung, Aktivierung" einfach sperrt und damit generell ein neues Log forciert.

So lässt sich auch im nachhinein die Log-Historie nachvollziehen. Vielleicht könnte man das Ticket zu einem Feature umschrieben ?

#3 Von bohrsty vor mehr als 4 Jahren aktualisiert

  • Tracker wurde von Bug zu Change geändert
  • Priorität wurde von 2 mittel zu 1 niedrig geändert
  • Kategorien wurde auf logs gesetzt

#4 Von Siggiiiiii vor fast 3 Jahren aktualisiert

Sehe ich auch so. Beim Editieren eines Logs sollte der Typ nicht mehr geändert werden dürfen (disabled). Wenn ein Anwender einen falschen Typ gewählt hat, muss er halt nochmal loggen oder sein Log löschen. Dazu ggf. eine Hinweismeldung einblenden. "Der Logtyp kann nicht nachträglich geändert werden, weil …"

Hat mEn Berührugspunkt zu http://redmine.opencaching.de/issues/709

#5 Von following vor fast 3 Jahren aktualisiert

Zumindest für Logs bis zum 25. Juli 2013 sollte der Typ änderbar bleiben. An diesem Tag wurde das Statuslogging eingeführt, und mit der Änderungsfunktion kann man alte, als Hinweis geloggte Wartungen nachtäglich kennzeichnen (und falls man sich dabei verklickt hat, sollte man das auch einfach rückgängig machen können).

#6 Von following vor mehr als 2 Jahren aktualisiert

  • Dupliziert durch Bug #862: Deaktivierungs-Log ohne Deaktivierung?! wurde hinzugefügt

#7 Von following vor mehr als 2 Jahren aktualisiert

  • Status wurde von neu zu offen geändert
  • Priorität wurde von 1 niedrig zu 3 hoch geändert

Hier muss eine Lösung her. Das von mic@ beschriebene Problem kommt immer wieder vor; oft sind dann Caches aktiv die eigentlich inaktiv sein sollten.

#8 Von following vor mehr als 2 Jahren aktualisiert

  • Beziehung mit Change #231: Mini-Feature Statuslogs sollten nicht mehr editierbar sein wurde hinzugefügt

#9 Von following vor mehr als 2 Jahren aktualisiert

  • Beziehung mit Change #709: Wartungslog besser benennen wurde hinzugefügt

#10 Von following vor mehr als 2 Jahren aktualisiert

Zusammenfassend mit #231 - ich denke man kann es so machen:

- Bei dem neuesten Log kann man den Typ beliebig ändern. Wird dann ggf. im Listingstatus nachgezogen, und das Änderungsdatum des Caches wird aktualisiert. Dass das Log nachträglich geändert wurde, wird ja seit Version 17 (#921) im Log gekennzeichnet, bleibt also synchron.

- Bei älteren Logs kann nur noch zwischen Fund/DNF/Hinweis gewechselt werden, nicht mehr zwischen Logtypen die den Cachestatus ändern.

Zu klären ist noch, wie es sich bei Logs mit/ohne Uhrzeit verhält. Es kann sein dass ein Log mit Uhrzeit da ist, und dann loggt der Owner eine Statusänderung ohne Uhrzeit die davor landet. Vielleicht sollte das nachträgliche Ändern für alle Logs am gleichen Tag freigegeben werden, solange es kein späteres Statusänderungslog gibt. Oder wollen wir Logs ohne Uhrzeit per Uhrzeit des Logeintrags einordnen? Das könnte Performance kosten, weil kein cache_logs-Index mehr verwendbar ist.

#11 Von following vor mehr als 2 Jahren aktualisiert

  • Tracker wurde von Change zu Bug geändert

following schrieb:

Oder wollen wir Logs ohne Uhrzeit per Uhrzeit des Logeintrags einordnen? Das könnte Performance kosten, weil kein cache_logs-Index mehr verwendbar ist.

-> #931

#12 Von following vor mehr als 2 Jahren aktualisiert

  • Zugewiesen an wurde auf following gesetzt

#13 Von following vor etwa 2 Jahren aktualisiert

  • Status wurde von offen zu in Arbeit geändert
  • Zielversion wurde auf Version 18 gesetzt

#14 Von following vor etwa 2 Jahren aktualisiert

  • Status wurde von in Arbeit zu erledigt geändert
  • % erledigt wurde von 0 zu 100 geändert

Beim neuesten Log kann man nun nachträglich den Cachestatus ändern, indem man den Logtyp ändert. Bei älteren Logs sind solche Änderungen des Typs nicht mehr möglich.

Auch abrufbar als: Atom PDF