Bug #336

Nachträgliche Logstatusänderung wirkungslos

Added by mic@ over 5 years ago. Updated over 3 years ago.

Status:erledigt% Done:

100%

Priority name:3 hoch
Assignee:following
Target version:Version 18
Ticket Referenz: Kategorien:logs

Description

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.


Related issues

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

Associated revisions

Revision 22e45486
Added by following over 3 years ago

improved handling of log type changes; updates #336

Revision 12c8a0ce
Added by following over 3 years ago

improved handling of log type changes; updates #336

History

#1 Updated by Schrottie over 5 years ago

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 Updated by Slini11 over 5 years ago

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 Updated by bohrsty over 5 years ago

  • Tracker changed from Bug to Change
  • Priority name changed from 2 mittel to 1 niedrig
  • Kategorien set to logs

#4 Updated by Siggiiiiii about 4 years ago

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 Updated by following about 4 years ago

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 Updated by following over 3 years ago

  • Duplicated by Bug #862: Deaktivierungs-Log ohne Deaktivierung?! added

#7 Updated by following over 3 years ago

  • Status changed from neu to offen
  • Priority name changed from 1 niedrig to 3 hoch

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 Updated by following over 3 years ago

  • Related to Change #231: Mini-Feature Statuslogs sollten nicht mehr editierbar sein added

#9 Updated by following over 3 years ago

  • Related to Change #709: Wartungslog besser benennen added

#10 Updated by following over 3 years ago

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 Updated by following over 3 years ago

  • Tracker changed from Change to Bug

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 Updated by following over 3 years ago

  • Assignee set to following

#13 Updated by following over 3 years ago

  • Status changed from offen to in Arbeit
  • Target version set to Version 18

#14 Updated by following over 3 years ago

  • Status changed from in Arbeit to erledigt
  • % Done changed from 0 to 100

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.

Also available in: Atom PDF