Mic@ hat [url=http://redmine.opencaching.de/issues/336]einen Bug gemeldet[/url], den ich selbst nicht wirklich als Bug sehe. Ich bitte mal um Meinungen dazu:
[quote="mic@"]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.[/quote]
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.
[Redmine 336] Logstatusänderung wirkungslos
-
Schrottie
[quote="mic@"]
Wieso?
Dias Bemerkungs-Log geht doch auch an alle Watcher raus.
[/quote]
Stichwort: FTF-Trick.
Hier besteht durchaus die Möglichkeit, das jemand einfach eine bestehende Note dazu nutzt um den Status eines Caches klammheimlich zu ändern. Das ist zwar sicher keine wirklich katastrophale Sache, aber Unfug ist es trotzdem. Wir haben ja die Statuslogs eingeführt, um hier nicht nur in den Logs die "Entwicklung" eines Caches sauber dokumentiert zu haben, sondern eben auch um Watchern sauber zu ermöglichen, den Überblick zu behalten.
Vertritt man nun die Auffassung, das auch das Bemerkungslog an alle Watcher rausgeht, dann muss man auch sicherstellen, das der Text dieser Bemerkung dahingehend überprüft wird, das genau die Aktion darin beschrieben ist, die die nun angegebene Statusänderung vornimmt. Es hilft ja nichts, wenn in der Bemerkung stand, das man nette Grüße von einem Cacher vor Ort erhalten hat, dann aber hinterher den Cache archiviert.
Wieso?
Dias Bemerkungs-Log geht doch auch an alle Watcher raus.
[/quote]
Stichwort: FTF-Trick.
Hier besteht durchaus die Möglichkeit, das jemand einfach eine bestehende Note dazu nutzt um den Status eines Caches klammheimlich zu ändern. Das ist zwar sicher keine wirklich katastrophale Sache, aber Unfug ist es trotzdem. Wir haben ja die Statuslogs eingeführt, um hier nicht nur in den Logs die "Entwicklung" eines Caches sauber dokumentiert zu haben, sondern eben auch um Watchern sauber zu ermöglichen, den Überblick zu behalten.
Vertritt man nun die Auffassung, das auch das Bemerkungslog an alle Watcher rausgeht, dann muss man auch sicherstellen, das der Text dieser Bemerkung dahingehend überprüft wird, das genau die Aktion darin beschrieben ist, die die nun angegebene Statusänderung vornimmt. Es hilft ja nichts, wenn in der Bemerkung stand, das man nette Grüße von einem Cacher vor Ort erhalten hat, dann aber hinterher den Cache archiviert.
[quote="Schrottie"]Es hilft ja nichts, wenn in der Bemerkung stand, das man nette Grüße von einem Cacher vor Ort erhalten hat, dann aber hinterher den Cache archiviert.[/quote]
OK, auch wenn Du gerade ein Szenario beschreibst, was ich für 0.01% aller Fälle für wahrscheinlich halte,
so kann ich es dennoch nachvollziehen und plädiere in diesem Fall dafür, daß ein Logtyp im nachhinein nicht
mehr geändert werden kann.
OK, auch wenn Du gerade ein Szenario beschreibst, was ich für 0.01% aller Fälle für wahrscheinlich halte,
so kann ich es dennoch nachvollziehen und plädiere in diesem Fall dafür, daß ein Logtyp im nachhinein nicht
mehr geändert werden kann.
Zuletzt geändert von mic@ am 13.11.2013, 11:06, insgesamt 1-mal geändert.
-
Schrottie
Den gleichen Prozentsatz kann man vermutlich auch für die Fälle ansetzen, in denen eine Note zu einem Statuslog gemacht werden soll. Jedoch muss dabei auch bedacht werden, dad zuweilen ein Admin einen Cache extra wegen der Statuslogs auf die Watchliste nimmt, einfach um damit immer im Blick zu haben wenn da später noch getrickst werden soll. Somit überwiegen die Vorteile, wenn man die nachträgliche Änderung in ein Statuslog verhindert.
Es muss eben bei einer entsprechenden Änderung nur aufgepasst werden, das in der "editlog.php" die Statuslogs nicht komplett gesperrt werden, denn wenn bspw. Der Text korrigiert werden soll, dann muss der originale Typ des jeweiligen Logs ja trotzdem verfügbar sein.
Es muss eben bei einer entsprechenden Änderung nur aufgepasst werden, das in der "editlog.php" die Statuslogs nicht komplett gesperrt werden, denn wenn bspw. Der Text korrigiert werden soll, dann muss der originale Typ des jeweiligen Logs ja trotzdem verfügbar sein.
-
Schrottie
[quote="OcRacher"]
Geht es nicht auch, dass ein Edit eines Logs erneut gesendet wird?
[/quote]
Das könnte dann schnell zu Spam werden. Wenn ich so daran denke, wie oft ich manchmal wegen fortgeschrittener Zerstreutheit ein Log bearbeite, dann würden die Watcher da schnell eine rappelvolle Mailbox haben.
Geht es nicht auch, dass ein Edit eines Logs erneut gesendet wird?
[/quote]
Das könnte dann schnell zu Spam werden. Wenn ich so daran denke, wie oft ich manchmal wegen fortgeschrittener Zerstreutheit ein Log bearbeite, dann würden die Watcher da schnell eine rappelvolle Mailbox haben.
-
OcRacher
Aber wenn man jedes mal einen neuen Log schreibt, werden es doch genau so viele. Oder über sehe ich jetzt was?
-
Schrottie
[quote="OcRacher"]
Aber wenn man jedes mal einen neuen Log schreibt, werden es doch genau so viele. Oder über sehe ich jetzt was?
[/quote]
Wenn ein neues Log zum Zwecke der Statusänderung geschrieben wird, ist die Mail ja durchaus erwünscht. Wenn dann aber für jede Änderung am Log eine weitere Mail rausgeht, dann ist das eher Spam.
Aber wenn man jedes mal einen neuen Log schreibt, werden es doch genau so viele. Oder über sehe ich jetzt was?
[/quote]
Wenn ein neues Log zum Zwecke der Statusänderung geschrieben wird, ist die Mail ja durchaus erwünscht. Wenn dann aber für jede Änderung am Log eine weitere Mail rausgeht, dann ist das eher Spam.
-
OcRacher
Da denke ich auch, den Text editierbar lassen, für Statusänderung einen neuen Eintrag. Da kann man es auch besser nachvollziehen.