Show who gave a favorite in cache listings and some work on filter/search

[DieBatzen]

In letzter Zeit habe ich die Zusatzfunktionen über den Logs in Cache Listings recht häufig verwendet und schätzen gelernt.

Dabei bin ich auch über einige Dinge gestolpert:

1. Reset-Button
   • das dynamische Nachladen der Logs beim Scrollen ist danach nicht mehr aktiv
   • es wird danach immer die aus den Settings ("Show at least x logs") angegebene Anzahl an Logs angezeigt, auch wenn vorher "Show all logs" gedrückt wurde oder Logs dynamisch nachgeladen wurden
2. Log Counter
   • werden bei den dynamisch nachgeladenen Logs nicht angezeigt
   • werden bei den Filtern oder der Suche im Log nicht angezeigt

Was noch wirklich klasse wäre, wenn man die Information, wer dem Cache einen Favoriten verpasst hat, besser verfügbar machen könnte.

Das habe ich mir mal angeschaut und eine Lösung gefunden, die um einiges schneller als die in #1054 bzw. #1454 funktionieren sollte:

• die Seiten https://www.geocaching.com/seek/cache_favorited.aspx?guid=... können nun geladen werden, ohne sie in einem separaten iframe anzeigen zu müssen
• die entscheidende Info zum Nachladen der nächsten Seite findet sich im versteckten input field "__VIEWSTATE" der aktuell geladenen Seite
• mit einem $.post(url, data), wobei "data" u.a. diese Infos mitschickt, klappt das wunderbar

Was leider nicht klappt, ist all die Seiten parallel zu laden, das muss immer noch eine nach der anderen passieren.
Aber für ein Listing mit mehr als 600 Favoriten ist das z.B. in etwa 12s erledigt und man kann währenddessen normal weiter arbeiten.

Ich habe das mal in meinem Fork in einen Branch eingebaut:
https://github.com/DieBatzen/GClh/blob/show-who-favorited-and-some-work-on-filter/search/gc_little_helper_II.user.js?raw=true

Und irgendwie bin ich dann auch gleich noch die Dinge mit dem Reset-Button und dem Log Counter angegangen, nun ist es eine etwas größere Änderung als eigentlich gedacht geworden.

So sieht es dann aus:

Ihr könnt euch das Ganze bei Gelegenheit ja mal anschauen, vielleicht kann man das so oder so ähnlich übernehmen.

[capoaira]

Moin,
Wahnsinn! Ich habe das mal bei einem meiner Caches ausprobiert und finde es super!👍🏻👍🏻👍🏻

Allerdings müssten wir uns, denke ich, eine Maximalgrenze an Favs suchen. Den Härtetest mit der Legogiraffe (GC13Y2Y) und über 1100 Seiten habe ich nach 11 Minuten abgebrochen 😅
Daher würde ich auch den 2. Config-Parameter infrage stellen, bei dem automatisch geladen wird (wenn ich das richtig verstanden habe)
Evtl. ist das auch nur eine Funktion für Owner?

Ansonsten super Sache, ich würde die Funktion sicher ab und an nutzen.😊

[DieBatzen]

Sehe ich auch so: eine Beschränkung des Ladens der Seiten sollte vorhanden sein.

Im Code ist aktuell eine Grenze von max. 100 Ladevorgängen über const maxCount = 100; eingebaut, also bis zu 1000 Finder, die einen Favorit vergeben haben.

Die Ladezeit der einzelnen Seiten ist allerdings von der Gesamtzahl der vergebenen Favoriten abhängig, da immer die komplette Info aller User über verschiedene __VIEWSTATE mit geschickt wird.
Bei der Legogiraffe sind das z.B. 118: __VIEWSTATE, ... __VIEWSTATE117, macht etwa 640 kB pro Seite.
Bei über 1000 Seiten kommt da einiges an Daten zusammen.
Und die Ladezeit ist um die 6s je Seite, mal 1000 Seiten ...

Im Vergleich dazu dauert das Laden der Seiten für einen Cache um die 1000 Favoriten (GC71BDX) etwa 80s, für einen um die 500 (GC2PKHN) etwa 20s.

Vielleicht ist es eine Idee, die Funktion nur für Caches bis zu einer gewissen Anzahl an Favoriten zu aktivieren (sonst ist der Button z.B. einfach deaktiviert). Ansonsten müssen einfach zu viele Daten übertragen werden und das dauert auch noch sehr lang.
Die Frage wäre dann, wie man das den Anwendern am besten verständlich macht.

Bei dem zweiten Config-Parameter fürs automatische Laden bei Seitenaufruf hast du vollkommen Recht - der macht bei langen Ladezeiten wenig Sinn.

[2Abendsegler]

Coole Sache! Der Button, das Laden, die Möglichkeit nur die Favoritenlogs anzuzeigen, alles super! Habe ich mir schon lange gewünscht und nicht nur ich. Ich hatte mich schon mehrfach daran versucht, zuletzt auch mit Get Favorited Users by Geocache, was ich aber nicht zum Laufen gebracht hatte, was aber bezüglich der Schnelligkeit vermutlich nicht zu schlagen wäre.

Super Feature!

Trotzdem habe ich eine Menge Anmerkungen und Punkte für die To-Do-Liste.
(Einige der Punkte dienen nur der Vollständigkeit. Die müssen jetzt nicht alle umgesetzt werden. Ich werde mich daran auch beteiligen. Ich werde die Liste bei Bedarf ergänzen.)

1. • Neues Feature implementieren.
2. • Automatisches Laden der Favoriten (zweiter Parameter) also nicht vorsehen.
3. • Ich bin auch dafür die Ladezeit und damit das Ladevolumen zu begrenzen. Die Ladevorgänge zu begrenzen macht vermutlich keinen Sinn, weil die Favoriten vermutlich durcheinander geladen werden und nicht etwa die zuletzt vergebenen Favoriten zuerst. Falls das so ist, finde ich die Idee prima, die Funktion nur für Caches bis zu einer gewissen Anzahl an Favoriten zu aktivieren. Vielleicht 500? Ansonsten deaktivieren des Buttons und vielleicht im title auf die zu vielen Favoriten hinweisen.
4. • (1.1) Dass nach dem Drücken des Reset-Buttons das dynamische Nachladen nicht mehr funktioniert ist ein Bug.
5. • (1.2) Dass nach dem Drücken des Reset-Buttons nur die laut Settings ("Show at least x logs") angegebene Anzahl an Logs angezeigt werden, ist so beabsichtigt. Damit kann man die Anzeige der Logs quasi neu starten auch für den Fall, dass der Browser mit der Anzeige der vielen Logs Probleme macht.
     Zwei Buttons: "Clear filter/search" und "Reset".
6. • Weiterer Bug zu "Search in logs". So wie beim Drücken des Buttons "Show all logs", sollten auch beim Drücken eines Log Types ... die Angaben bei "Search in logs" zurückgesetzt werden. Diesen Bug habe ich schon ewig auf meiner Liste.

7. (2.2) Die Log Counter werden bei den Filtern oder der Suche im Log nicht angezeigt. Das gilt auch bei einer Änderung bei "Order by". Das ist so beabsichtigt, um Nachfragen zu verhindern, die darauf abzielen, die nicht fortlaufende Nummerierung zu beanstanden. Immer dann, wenn man die "normale" Ablistung der Logs verlässt, sollen die Log Counter zurückgesetzt werden und eine neue Anwahl auch verhindert werden, weshalb der Button ausgeblendet oder deaktiviert wird bis die "normale" Ablistung der Logs wieder angewendet wird.

8. • (2.1) Die Log Counter werden bei den dynamisch nachgeladenen Logs nicht angezeigt. Das ist nicht unbedingt notwendig, war aber im Zuge von 6. 7. so beabsichtigt, wenn ich mich richtig erinnere. Das könnte man ändern, dann müsste man aber sicherstellen, dass nur bei der "normalen" Ablistung der Logs auch die Log Counter dynamisch mit den Logs nachgeladen werden.

9. Zum Umfang der Änderungen.
   Für gewöhnlich machen wir keine Änderungen am Coding, sofern es funktioniert, mal abgesehen von Beschreibungen und formalen Dingen wie beispielsweise dem Setzen von ";" am Zeilenende. Naja, das ist hauptsächlich meine Regel. Das gilt auch für Zusammenfassungen von Coding das mehrfach vorhanden ist, oder auch bei holprig eingebautem Coding, was hier vielfach der Fall ist. Im Besonderen gilt das für Themen die ziemlich komplex sind oder bei denen eine Fehlfunktion heikel ist, so wie es hier der Fall ist.
   Das hat im Wesentlichen drei Gründe. Zum einen wollen wir das Coding von anderen Entwicklern respektieren. Wenn etwas an einem Coding verbesserungswürdig ist, dann sollte das vor der Implementierung oder direkt danach mit entsprechendem Hinweis an den Entwickler erfolgen.
   Zum anderen, und das ist noch wichtiger, wollen wir die Fehlerfreiheit bestehender Features nicht gefährden. Je umfangreicher die Änderungen sind, desto wahrscheinlicher sind eben auch Fehler. Fehler, die aufgrund von Änderungen im Coding passieren, die gar nicht notwendig sind, können wir gegenüber den Usern kaum rechtfertigen.
   Und letztens wollen wir den Umfang notwendiger Tests so gering wie möglich halten, einfach weil wir begrenzte Kapazitäten haben.
   Thomas, bitte verstehe mich nicht falsch. Ich bin tatsächlich immer sehr froh, wenn du hier Beiträge bringst, schon weil sie vielfach außergewöhnliche Features beinhalten, und auch Features betreffen, an denen wir uns schon mehrfach die Zähne ausgebissen haben, so wie auch hier. Ich versuche lediglich eine sinnvolle Balance zwischen den Freiheiten der Entwickler, unserem Aufwand und den Usern zu finden.
   Vielleicht ist es möglich, dass die Änderungen am Coding möglichst auf das neue Feature und die Bugs beschränkt werden.

10. Probleme, die mir bei meinen kurzen Tests aufgefallen sind. Wenn nur das neue Feature eingebaut und die Bugs beseitigt werden, sollten sich einige der Probleme schon erledigt haben.

• 1. Wenn ich einen Log Type oberhalb der Logs angewählt habe, klappt anschließend das "Order by" Dropdown Menü nicht mehr auf.
• 2. Die Buttons "Show all logs" und "Show bigger avatars" dürfen nicht deaktiviert werden. Wenn ich sie einmal angewählt habe, dann beispielsweise einen Log Type oberhalb der Logs anwähle, müssen sie anschließend zur erneuten Auswahl zur Verfügung stehen.
• 3. Entsprechend den Punkten 6. und 7. 7. und 8. sollte auch der Button "Show log counter" nach dem Drücken nicht deaktiviert bleiben.
• 4. Die Buttons sollten mit einer Breite von 950 Pixeln (""Page width 950 px") ohne Umbruch angezeigt werden. Die Beschreibung der Buttons sollte also bei kleinen Pixel Angaben gekürzt werden.

[DieBatzen]

Danke euch beiden für das ausführliche Feedback, ich werde mich revanchieren. :)

Coole Sache! Der Button, das Laden, die Möglichkeit nur die Favoritenlogs anzuzeigen, alles super! Habe ich mir schon lange gewünscht und nicht nur ich. Ich hatte mich schon mehrfach daran versucht, zuletzt auch mit Get Favorited Users by Geocache, was ich aber nicht zum Laufen gebracht hatte, was aber bezüglich der Schnelligkeit vermutlich nicht zu schlagen wäre.

Das wäre natürlich perfekt.
In der Web-API gibt es leider noch keine solche Funktion, die könnte man dann wunderbar nutzen.

Super Feature!

Trotzdem habe ich eine Menge Anmerkungen und Punkte für die To-Do-Liste. (Einige der Punkte dienen nur der Vollständigkeit. Die müssen jetzt nicht alle umgesetzt werden. Ich werde mich daran auch beteiligen. Ich werde die Liste bei Bedarf ergänzen.)

1. * [ ]  Neues Feature implementieren.

2. * [ ]  Automatisches Laden der Favoriten (zweiter Parameter) also nicht vorsehen.

3. * [ ]  Ich bin auch dafür die Ladezeit und damit das Ladevolumen zu begrenzen. Die Ladevorgänge zu begrenzen macht vermutlich keinen Sinn, weil die Favoriten vermutlich durcheinander geladen werden und nicht etwa die zuletzt vergebenen Favoriten zuerst. 

Genau, die User sind alphanumerisch sortiert, völlig losgelöst von der Logreihenfolge.
Um sie chronologisch korrekt anzuzeigen, müssen immer alle geladen werden.

Falls das so ist, finde ich die Idee prima, die Funktion nur für Caches bis zu einer gewissen Anzahl an Favoriten zu aktivieren. Vielleicht 500?

Ja, 500 könnte ein ganz akzeptabler Kompromiss sein.
Können wir dann immer noch tunen - in die eine oder andere Richtung.

Ansonsten deaktivieren des Buttons und vielleicht im title auf die zu vielen Favoriten hinweisen.

Gute Idee.

4. * [ ]  (1.1) Dass nach dem Drücken des Reset-Buttons das dynamische Nachladen nicht mehr funktioniert ist ein Bug.

5. (1.2) Dass nach dem Drücken des Reset-Buttons nur die laut Settings ("Show at least x logs") angegebene Anzahl an Logs angezeigt werden, ist so beabsichtigt. Damit kann man die Anzeige der Logs quasi neu starten auch für den Fall, dass der Browser mit der Anzeige der vielen Logs Probleme macht.

Das macht natürlich total Sinn, speziell bei sehr vielen Logs mit vielen Bildern - da wird der Browser zickig.

Einen Nachteil gibt es dabei:
Werden bei der "normalen" Ablistung der Logs weitere Logs dynamisch nachgeladen, dann ein Filter gesetzt (oder in den Logs gesucht), so kommt man nur über Reset wieder zurück - und dabei werden alle zuvor dynamisch geladenen Logs verworfen und müssen bei Bedarf erneut geladen werden.

Um das zu vermeiden habe ich einen Parameter cachedLogs = $('#cache_logs_table2>tbody').clone(); eingebaut, der den "aktuellen Zustand" speichert und nach Rückkehr von Filter/Search einfach wieder herstellt.
Daher auch der Name "Clear filter" im Reset Button.

Vielleicht wäre beides sinnvoll?
Ein "Clear filter/search" Button, der nach Rückkehr von Filter/Search den vorherigen Zustand wieder herstellt und ein "Reset" Button, der die Anzeige der Logs in den Anfangszustand zurücksetzt.
Wäre dann halt ein Button zusätzlich, Platz gäbs ja in der Zeile noch ...

6. * [ ]  Weiterer Bug zu "Search in logs". So wie beim Drücken des Buttons "Show all logs", sollten auch beim Drücken eines Log Types ... die Angaben bei "Search in logs" zurückgesetzt werden. Diesen Bug habe ich schon ewig auf meiner Liste.

7. (2.2) Die Log Counter werden bei den Filtern oder der Suche im Log nicht angezeigt. Das gilt auch bei einer Änderung bei "Order by". Das ist so beabsichtigt, um Nachfragen zu verhindern, die darauf abzielen, die nicht fortlaufende Nummerierung zu beanstanden. 

Genau darüber bin ich auch kurz gestolpert, bis ich verstanden habe, dass der erste Wert die Logytpen durchnummeriert.
Die nicht fortlaufende Nummerierung ist zwar auch aktuell in den Logs sichtbar, würde aber durch Anzeige in den Filtern erst so richtig auffallen.
Da kann ich deinen Einwand voll und ganz nachvollziehen - ich muss die Nachfragen ja schließlich nicht beantworten. :):):)

Immer dann, wenn man die "normale" Ablistung der Logs verlässt, sollen die Log Counter zurückgesetzt werden und eine neue Anwahl auch verhindert werden, weshalb der Button ausgeblendet oder deaktiviert wird bis die "normale" Ablistung der Logs wieder angewendet wird.

8. * [ ]  (2.1) Die Log Counter werden bei den dynamisch nachgeladenen Logs nicht angezeigt. Das ist nicht unbedingt notwendig, war aber im Zuge von ~6.~ 7. so beabsichtigt, wenn ich mich richtig erinnere. Das könnte man ändern, dann müsste man aber sicherstellen, dass nur bei der "normalen" Ablistung der Logs auch die Log Counter dynamisch mit den Logs nachgeladen werden.

Das klappt ziemlich einfach über einen Aufruf von showLogCounter(); in gclh_dynamic_load.

9. Zum Umfang der Änderungen.
   Für gewöhnlich machen wir keine Änderungen am Coding, sofern es funktioniert, mal abgesehen von Beschreibungen und formalen Dingen wie beispielsweise dem Setzen von ";" am Zeilenende. Naja, das ist hauptsächlich meine Regel. Das gilt auch für Zusammenfassungen von Coding das mehrfach vorhanden ist, oder auch bei holprig eingebautem Coding, was hier vielfach der Fall ist. Im Besonderen gilt das für Themen die ziemlich komplex sind oder bei denen eine Fehlfunktion heikel ist, so wie es hier der Fall ist.
   Das hat im Wesentlichen drei Gründe. Zum einen wollen wir das Coding von anderen Entwicklern respektieren. Wenn etwas an einem Coding verbesserungswürdig ist, dann sollte das vor der Implementierung oder direkt danach mit entsprechendem Hinweis an den Entwickler erfolgen.
   Zum anderen, und das ist noch wichtiger, wollen wir die Fehlerfreiheit bestehender Features nicht gefährden. Je umfangreicher die Änderungen sind, desto wahrscheinlicher sind eben auch Fehler. Fehler, die aufgrund von Änderungen im Coding passieren, die gar nicht notwendig sind, können wir gegenüber den Usern kaum rechtfertigen.
   Und letztens wollen wir den Umfang notwendiger Tests so gering wie möglich halten, einfach weil wir begrenzte Kapazitäten haben.
   Thomas, bitte verstehe mich nicht falsch. Ich bin tatsächlich immer sehr froh, wenn du hier Beiträge bringst, schon weil sie vielfach außergewöhnliche Features beinhalten, und auch Features betreffen, an denen wir uns schon mehrfach die Zähne ausgebissen haben, so wie auch hier. Ich versuche lediglich eine sinnvolle Balance zwischen den Freiheiten der Entwickler, unserem Aufwand und den Usern zu finden.

Überhaupt kein Problem, verstehe ich komplett.

Mir war am Ende schon klar, dass das eigentlich zu viele Änderungen auf einmal sind.
Aber irgendwie kam eins zum anderen ... und es lief so gut.

   Vielleicht ist es möglich, dass die Änderungen am Coding möglichst auf das neue Feature und die Bugs beschränkt werden.

Auch da habe ich überhaupt keine Einwände, kann ich in einem separaten Branch einbauen.

10. Probleme, die mir bei meinen kurzen Tests aufgefallen sind. Wenn nur das neue Feature eingebaut und die Bugs beseitigt werden, sollten sich einige der Probleme schon erledigt haben.


* [ ]  1. Wenn ich einen Log Type oberhalb der Logs angewählt habe, klappt anschließend das "Order by" Dropdown Menü nicht mehr auf.

* [ ]  2. Die Buttons "Show all logs" und "Show bigger avatars" dürfen nicht deaktiviert werden. Wenn ich sie einmal angewählt habe, dann beispielsweise einen Log Type oberhalb der Logs anwähle, müssen sie anschließend zur erneuten Auswahl zur Verfügung stehen.

* [ ]  3. Entsprechend den Punkten ~6. und 7.~ 7. und 8. sollte auch der Button "Show log counter" nach dem Drücken nicht deaktiviert bleiben.

* [ ]  4. Die Buttons sollten mit einer Breite von 950 Pixeln (""Page width 950 px") ohne Umbruch angezeigt werden. Die Beschreibung der Buttons sollte also bei kleinen Pixel Angaben gekürzt werden.

1-3 dürften sich automatisch erledigen, wenn nur das neue Feature eingebaut ist.

[DieBatzen]

Das Feature (und nur das) ist nun in einem neuen Branch implementiert:
https://github.com/DieBatzen/GClh/blob/show-who-favorited-in-cache-listings/gc_little_helper_II.user.js?raw=true

• kein automatisches Laden beim Aufruf des Listings möglich (also kein zweiter Parameter)
• die Funktion muss und kann nur einmal ausgeführt werden, danach ist der Button deaktiviert
• Ladezeit und damit Ladevolumen zu begrenzen hatte ich zunächst für Caches mit mehr als 500 Favoriten eingebaut, hat mich beim Testen aber nicht überzeugt.
  Stattdessen kommt nun für Caches mit mehr als 500 Favoriten eine Bestätigungsabfrage (mit erklärendem Text), bei der der Anwender selbst entscheidet ob er fortfährt oder abbricht.
  Ich denke das ist ein guter Kompromiss zwischen Ladezeit/Ladevolumen begrenzen und Funktionalität einschränken.

Bugs sind in dem Branch noch keine gefixt.

[2Abendsegler]

zu 3. Ladezeit und Ladevolumen begrenzen.

Eigentlich geht es nicht nur darum das Ladevolumen beim Anwender zu begrenzen, sondern auch bei GS. Nach meiner Einschätzung ist das Laden solcher Daten nicht erlaubt. Mal abgesehen von den Logs eines Caches, die wir alle im Hintergrund laden, versuchen wir die GS Server deshalb möglichst wenig zusätzlich zu belasten. Wir möchten nicht, dass GS diesbezüglich auf uns aufmerksam wird.

Wenn über Minuten permanent Daten zu den Favoriten geladen werden, wird das bei GS womöglich nicht unbeobachtet bleiben.

Ich bin hier also hin und her gerissen, ob wir eine Begrenzung einbauen sollen.

@capoaira Was meinst du?

---

zu 5. Nach Drücken des Reset-Buttons nur Startanzeige der Logs.

Vielleicht wäre beides sinnvoll?
Ein "Clear filter/search" Button, der nach Rückkehr von Filter/Search den vorherigen Zustand wieder herstellt und ein "Reset" Button, der die Anzeige der Logs in den Anfangszustand zurücksetzt.
Wäre dann halt ein Button zusätzlich, Platz gäbs ja in der Zeile noch ...

Finde ich gut. Habe ich als To Do oben aufgenommen. Vielleicht erklären wir noch im title was der Reset Button macht. Bei "Clear filter/search" scheint das ja schon mal klar.

---

zu 8. Log Counter beim dynamischen Nachladen.

Das klappt ziemlich einfach über einen Aufruf von showLogCounter(); in gclh_dynamic_load.

Ja, bei den Filtern oder beim Search wird ja sowieso nicht nachgeladen. Wir müssten lediglich noch verhindern, dass bei einer anderen Sortierung über "Oder by" die Log Counter nachgeladen werden, dann können wir das so machen.

---

Bugs sind in dem Branch noch keine gefixt.

Ja das ist gut so, zuerst das neue Feature und danach sehen wir weiter.

---

Ich bin noch nicht dazu gekommen, mir deine neue Entwicklung anzusehen, sorry. Ich werde es über die Woche versuchen.

[2Abendsegler]

Sorry, es hat doch etwas länger gedauert, obwohl ich die Tests schon Ende letzter Woche gemacht hatte.

Ich kann mich einfach nicht damit anfreunden, in diesem Umfang Daten nach zu laden. Genau genommen finde ich 20 bis 23 Sekunden für etwa 500 Favoriten schon grenzwertig. Für etwa 1000 ist über eine Minute und für etwa 4000 sind fast 14 Minuten bei mir notwendig gewesen, wo ununterbrochen Daten angefordert wurden.

Nicht jeder Anwender wird es in Ordnung finden, wenn wir eine Grenze für die Anzahl der Favoriten ziehen, bis zu der wir das Feature anbieten. Andererseits würden einige die genannten Laufzeiten aber auch nicht in Ordnung finden. So oder so gute Voraussetzungen für eine glühende Nachrichtenbox.

Bitte lass uns das Feature auf 500 Favoriten begrenzen. Wenn du möchtest kannst du einen PR aufmachen. Im Config gibt es noch einen kleinen Fehler. Ich werde mir das dann noch mal anschauen.

[DieBatzen]

Kein Problem, dann beschränken wir das Feature auf max. 500 Favoriten (z.B. https://coord.info/GC71BDX):

In den Settings wird darauf auch explizit hingeweisen:

Zumindest die Gesamtzeit lässt sich über gleichzeitiges Verarbeiten von "First-Next" und "Last-Previous" noch auf grob die Hälfte reduzieren (Cache mit 486 Favoriten (https://coord.info/GC2PKHN) benötigt bei mir ca. 12,5s):

Die Datenmenge, die für diesen Cache heruntergeladen werden muss, beträgt etwa 3,1 MB.
Beides scheint mir für diesen "Extremfall", wenn auch nicht wirklich gut, doch recht akzeptabel zu sein.

Ein PR ist erstellt, könnt ihr euch bei Gelegenheit ja mal anschauen.

[capoaira]

I've deleted and reported the spam message.

---

Ich habe die Spam Nachricht gelöscht und gemeldet.

[chrkaatz]

@capoaira ich wurde auf der Nachricht mentioned und bin deswegen etwas verwundert. Was war das?

[chrkaatz]

Ahh, jetzt habe ich es gefunden - im Spam-Ordner. Sowas nervt.