Falsche Änderungsdaten bei 40.000 Logs und 700 Cachelistings - wie vorgehen?

[following]

Vorgestern haben durch eine manuelle Änderung in der OC-Datenbank ca. 40.000 Logs und 700 Cachelistings die Markierung "zuletzt geändert am 14. Februar 2017" bekommen. Das sieht nun so aus, als hätten die Logger die Logs nacheditiert und die Owner die Cachebeschreibungen geändert. Tatsächlich sehen die Logs und Beschreibungen aber noch exakt genauso aus wie vorher.

Es ist technich möglich, das zu korrigieren und diese Daten zu >99% wieder auf den alten Stand zu bringen. Ich bekam aber eben vom OC-Entwicklungsvorstand (nachzulesen in Redmine-Ticket #1033) ohne weitere Diskussion oder Begründung die Antwort: "Wir werden das Datum nicht ändern." Stattdessen würde im Blog und OC-Talk darüber informiert.

Was haltet ihr davon? Wäre es nicht sinnvoller, diese Einträge zu korrigieren?

[mic@]

Das sieht nun so aus, als hätten die Logger die Logs nacheditiert und die Owner die Cachebeschreibungen geändert.

Was ist daran nun so schlimm?
Wenn Logs / Caches verloren gegangen wären, dann würde ich Dir zustimmen,
aber so handelt es sich doch "nur" um ein Änderungsdatum, was sogar passend
gesetzt ist, nur eben die falschen Schlussfolgerungen erlaubt. Also ich vermute mal,
das werden die Wenigsten wirklich bemerken.

[Samsung1]

Das soll so bleiben? 0o  Ich finde das reichlich unschön und es wirkt mega dilettantisch. Das stärkt nicht gerade die Akzeptanz der Plattform.  : \

[mic@]

Ich finde das reichlich unschön und es wirkt mega dilettantisch.

Dann auch die Frage an Dich: Was ist daran nun so schlimm?
Ich finde, hier wird aus einer Mücke ein Elefant gemacht.
Das einzige, was dadurch nun "falsch" ist, ist das neue Änderungsdatum.
Und technisch betrachtet ist dies ja noch nicht einmal falsch, denn es wurde ja etwas verändert.
Also in meinen Augen ist das hier kein Grund, so ein Fass aufzumachen.
Just my 0.02 Euro, Mic@

[FlashCool]

Für mein Dafürhalten ist das ein eindeutiger Fehler seitens OC, der da passiert ist und der sollte so schnell wie möglich behoben werden. Ich kann mich der Meinung von Samsung1 nur anschließen. Für den Benutzer ist das so nicht nachvollziehbar und wirft Fragen auf, "stärkt" nebenbei auch das Misstrauen hinsichtlich Entwicklerkompetenzen.

[Q-Owls]

Es ist technich möglich, das zu korrigieren und diese Daten zu >99% wieder auf den alten Stand zu bringen.

Das mal was schief geht ist normal.
Aber wenn machbar sollte man es  wieder in Ordnung bringen!

[ClanFamily (Mirco)]

@FlashCool:
Hi. Es gab die Notwendigkeit, defekte Smilies in den Beschreibungen zu reparieren.
Dies wurde erledigt. Damit einhergehend wurde der Datensatz verändert. Das ist ein technischer Prozess und hat nichts mit Entwicklerkompetenz zu tun.
Logischer Weise ist es damit korrekt, dass das Änderungsdatum aktualisiert wurde (was nicht die Absicht war, sondern durch einen Datenbank Trigger funktionierte)

@Q-Owls:
Das Rückschreiben der Änderungen hat diverse Seiteneffekte inkl. entsprechendem Aufwand.
Das Entwicklerteam hat entschieden, hinter diesem Vorgang zu stehen und eine Lösung für die Zukunft zu finden.
Das wir im OC Support, mit Unterstützung von der Entwicklung Eingriffe in die Datensätze vornehmen, bleibt nicht aus.

Lerneffekt:
Es handelt sich hier rein um einen Datumsstempel, der keine Auswirkung auf Statsitik, Punke oder sonst was hat - außer, dass dort steht, das der Datensatz geändert wurde und nicht von wem.
Wir haben daher beschlossen, die notwendigen Eingriffe von uns, in naher Zukunft (ist bereits in der Entwicklung), per Audit Log kenntlich zu machen.
Somit ist klar, was haben wir wann geändert - ggfls mit Erklärung warum.

Wir verfassen darüber hinaus einen Blogbeitrag und besprechen diesen Fall im kommenden OC Talk.

[Q-Owls]

Habe verstanden. Macht Sinn so.

[following]

@FlashCool:
Hi. Es gab die Notwendigkeit, defekte Smilies in den Beschreibungen zu reparieren.

Es gab und gibt keine Notwendigkeit, die Inhalte der Logs und Beschreibungen zu verändern. Für die Smilies wurde bereits eine andere Lösung gefunden; die Manipulation der von den Benutzern beigetragenen Inhalte ist völlig überflüssig.

Das Rückschreiben der Änderungen hat diverse Seiteneffekte inkl. entsprechendem Aufwand.

Nein, es gäbe keine relevanten "Seiteneffekte". Den Aufwand bestünde darin, dass ein Datenbankdump aus dem Backup geholt wird, und dass ich mich ein paar Stunden hinsetze und die Daten repariere. Kein Problem.

Das wir im OC Support, mit Unterstützung von der Entwicklung Eingriffe in die Datensätze vornehmen, bleibt nicht aus.

Der Support greift nur bei Listingvandalismus in Listinginhalte ein; alles andere ist tabu. Davon abgesehen sind Eingriffe auch bei defektem HTML-Code notwendig, dafür ist die Entwicklung zuständig.

In Fällen wie diesem hier ist ein Eingriff (er erfolgte im Alleingang durch die Entwicklung) unnötig.

Habe verstanden. Macht Sinn so.

Nein, macht keinen Sinn.


Allen Beteiligten ist klar dass das Ganze Mist ist, aber die Verantwortlichen sind nicht bereit den Mist wieder in Ordnung zu bringen, weil sie selbst nicht wissen wie es geht - und derjenige, der weiß, wie es geht, wird aus "politischen" Gründen daran gehindert, es zu reparieren. Auf Kosten der Nutzer.

[following]

Zur Erklärung für diejenigen, die was von Softwareentwicklung verstehen (die anderen bitte ignorieren):

• Das Ein Verzeichnis, in dem die Smiley-Grafiken liegen, wurde verschoben. Dadurch waren Smileys in vorhandenen Logs und Cachbeschreibungen defekt.
• Ich habe darauf hingewiesen, dass das Verzeichnis wiederhegestellt werden muss, damit die Smilies wieder funktionieren.
• Stattdessen hat jemand die Smiley-URLs in den Logs und Beschreibungen ausgetauscht, mit dem Ergebnis, dass das Änderungsdatum manipuliert wurde.
• Diese Lösung war für die Katz, weil die alten Smiley-Pfade trotzdem weiterhin gebraucht werden (können extern verlinkt sein; können bei Vandalismus-Rücksetzung wieder entstehen.)
• Daraufhin wurde eine andere, einfach umsetzbare Lösung gefunden, die ohne Manipulation der Logs und Beschreibungen auskommt und die nun implementiert werden soll. (alten Pfad per httpd-Rewrite bereitstellen)

... und trotzdem wird weiter an der Datumsmanipulation festgehalten. Sie ist unnötig und lässt sich rückgängig machen, und trotzdem hält man daran fest.

[Edit: Punkt 1 oben korrigiert; siehe Beitrag #20]

[Samsung1]

Ich finde das reichlich unschön und es wirkt mega dilettantisch.

Dann auch die Frage an Dich: Was ist daran nun so schlimm?

• Ich persönlich mag es nicht, wenn jemand meine Daten verändert. Dass Ihr da im Hintergrund scheinbar die Smileys irgendwie transformiert kommt mir gruselig genug vor aber es scheint ja einem guten Zweck zu dienen. Ich hätte am liebsten nie davon erfahren .
• Es wirft so die Frage auf, was ihr noch so alles im Namen des Nutzers entfernt oder ergänzt.
• Das geändert am $datum erweckt den Anschein, dass der Nutzer diese Änderung durchgeführt hat. Das ist schlichtweg falsch. Wenn ihr so etwas schon machen wollt, dann schreibt darunter Geändert am $datum durch das OC-Team. Ich mache jetzt hier jetzt mal den Advocatus Diaboli: Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

 

Das ist ein technischer Prozess und hat nichts mit Entwicklerkompetenz zu tun.

Eben weil es ein technischer Prozess ist, würde ich sagen, dass er verdammt viel mit Entwicklerkompetenz zu tun hat .


So viel zu meinen zwei Cent. Die Welt geht davon nicht unter - aber ich kann nur wiederholen, was ich oben gesagt habe: Ich finde das reichlich unschön und es wirkt mega dilettantisch.

[mic@]

Es wirft so die Frage auf, was ihr noch so alles im Namen des Nutzers entfernt oder ergänzt.

Du kennst diesen Thread hier? http://forum.opencaching.de/index.php?topic=4203.msg55638#msg55638
Auch diese Änderungen geschahen zum Wohle von OC.

Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

Wieso falsche Tatsachen. Es wurde ja zu diesem Zeitpunkt etwas geändert.
Also kein Grund zur Panik 

[following]

Ich mache jetzt hier jetzt mal den Advocatus Diaboli: Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

Wir haben auch eine Opencaching.de-Datenlizenz, die die Veränderung des von Benutzern beigetragenen Contents verbietet (CC ND). Nun wird überflüssigerweise der Eindruck erweckt, dass genau das passiert ist, obwohl de facto gar keine Änderung an dem erfolgt ist was der Nutzer eingegeben hat.

Wenn es tatsächlich notwendig wäre, solche Dinge nachträglich zu ändern (was hier nicht der Fall ist), dann kann man das mit Nachfilterung vor der Ausgabe des HTML-Codes machen, wie es bereits bei http-Bildpfaden in https-Seiten der Fall ist. In den Datenbankinhalten rumpfuschen ist nicht nötig.

[Samsung1]

Haben wir da nicht irgendwie Gesetze mit einem Straftatbestand "Vortäuschung falscher Tatsachen"?

Wieso falsche Tatsachen. Es wurde ja zu diesem Zeitpunkt etwas geändert.
Also kein Grund zur Panik 

Ich bin kein Jurist. Es erweckt den Anschein. Denke doch, das reicht.

Du kannst uns im relativ geschlossenen Kreis jetzt hier darlegen, warum diese Änderung sinnvoll war. Ich vertraue euch soweit, dass ich euren guten Willen als gegeben hinnehme. Aber eure Änderung hat eine immense Strahlkraft. Jeder, der so ein Log liest, bekommt potentiell ein ungutes Gefühl. Und diese Leute habt ihr damit geprägt. Die wenigsten von denen werden im Forum eine Erklärung suchen. So sind die Menschen nun mal.

[Jiver78]

Ich bin kein Jurist, aber...

Im letzten OC-Talk ging es um einen Copyright-Verstoß in einem Cachelisting, und dass der Owner das Anwaltsschreiben weitergelteitet bekam. Er ist ja als Publizierer des Caches für den Inhalt verantwortich.

Wenn OC nun Änderungen an den Cachelistings durchführt, egal wie marginal diese sind, wird OC selbst zum (Mit-)Publizierer des Listings und damit mit für den Inhalt verantwortlich.

Einzige Folgerung daraus: sowohl das Änderungsdatum muss zurückgesetzt als auch die Inhalte wiederhergestellt werden.