Closed 2Abendsegler closed 5 years ago
Wenn du willst schau ich auch mal rein, ob es vielleicht eine schnelle/einfache Lösung gibt, aber ich vertrau auch gern deinem Urteil. Und wenn es so aufwendig ist, dann sollte wir es zur Zeit nicht umsetzen.
Ja, schau bitte irgendwann mal rein, ob dir vielleicht eine schnelle/einfache Lösung einfällt, du bist technisch viel besser. Ich setz das mal auf Prio low, damit wir zuerst mal die Karte und die Bewertung der Logs fertigstellen können.
@2Abendsegler ich hab mal rein geschaut und 5 Minuten gebastelt: https://github.com/Ruko2010/GClh/raw/issue/1011-reviewer_as_VIP/gc_little_helper_II.user.js
Es ist noch nicht fertig uns auch noch nicht perfekt. Aber zur Verdeutlichung vielleicht ausreichend. Schaus dir mal an. Natürlich müsste noch ein Schalter gebaut werden um die Option an/aus zu machen. Problem ist auch schon wie von dir angesprochen, dass es nur Reviewer findet, die aktuell Reviewer sind! Man könnte das ganze noch ausbauen und sagen, setz den als Reviewer, der den Publish Log gemacht hat. Die Frage ist, macht das Sinn?
Ich hab mal noch den "Publisher" eines Caches als "Reviewer" mit aufgenommen. Beispiel siehe hier: https://www.geocaching.com/geocache/GC46ZCH
So hat man immer den Cacher, der entweder Reviewer ist, oder der den Cache gepublished hat, auch wenn er kein Reviewer mehr ist mit in der VIP-Liste.
Ja, das sieht schon mal gut aus!
Hast du nichts zu tun oder was? Das ist doch prio: low ... gröl
Ich glaube hier liegt das Grauen im Detail! Hab mal kurz auf den VIP Button eines Reviewers in der found Liste gedrückt. Das ist das Ergebnis ...
Ich weiß du bist noch nicht fertig. ;)
Folgende Punkte wären wohl noch sinnvoll:
[Edit] Punkte
Ich brauchte mal wieder ein Erfolgserlebnis 😃. Ich hab mich mal mit der neuen Karte beschäftig und irgendwie klappt da nix 😔. Das hier hab ich mir echt nur mal 5 Minuten angeschaut, darum ist es auch noch so "unausgegoren" 😃. Meinst du wirklich wir brauchen 2 Konfig-Parameter? Können wir den nicht einfach "Enable Reviewer/Publisher as VIP" nennen? Die anderen Punkte werd ich noch machen. Sieht aus, als ob das schnell geht. Soll das "Reviewer" vor dem Namen immer da sein, auch wenn der User ein "normaler" VIP ist?
Die ersten drei Punkte sind eingebaut. Ich warte noch auf die Antwort wegen dem Schalter, dann bau ich den auch noch ein.
Achso, das mit der "NotFound"-Liste ist ja kein Bug, da du den Reviewer zu deinen VIPs hinzugefügt hast, richtig? Denn er taucht dort nicht auf, wenn er kein VIP ist, was ja an sich richtig ist.
Sorry für die späte Reaktion, war heute noch nicht Online.
So, Schalter ist auch eingebaut. Kannst ja nochmal drüber gucken.
Integrate reviewer in VIP lists.
http://geoclub.de/forum/viewtopic.php?f=117&t=80208&p=1295154#p1295154
Zusammenfassung: Ursprünglich ging es darum im Cache Listing mit einem Klick ganz nach unten zum ältesten Log zu springen. Der Lösungsvorschlag lautet nun, Reviewer in die VIP Listen zu integrieren, ähnlich wie das für den Owner realisiert ist, so dass man per Mausklick auf das Publish Icon beim Reviewer zum quasi ältesten Log springen kann.
Meine Einschätzung zu diesem Lösungsvorschlag: Grundsätzlich ist es keine blöde Idee den Reviewer ebenfalls in die VIP Listen aufzunehmen, wie ich finde, schließlich können dessen Logs schon von großer Bedeutung sein. Ich habe mir das mal grob angesehen, das Thema ist nicht ohne weil es insbesondere mehrere Reviewer geben kann. Wir können also nicht wie beim Owner agieren, den es immer genau einmal gibt, sondern müssen mit einem array operieren. Wir blähen damit das ohnehin komplexe VIP Coding an etlichen Stellen ziemlich auf. Als Lösungsvorschlag für das benannte Problem ist es nicht wirklich treffsicher, weil es doch einige Ausnahmen gibt (In alten Listings gibt es keinen Publish; Reviewer wird in normalen User gewandelt, wir können ihn nicht ohne weiteres als Reviewer erkennen ...). Der Feature Request wird nun aber ohne die ursprüngliche Problematik benannt und ich fand die Idee ja auch nicht schlecht. Ich tendiere trotzdem nach allem dahin, dass wir diesen Request nicht umsetzen, weil mir der Aufwand gegenüber dem Nutzen zu hoch erscheint, insbesondere auch der Testaufwand bis alles rund läuft. Wenn überhaupt sollten wir das ganz nach hinten schieben. Wir haben einige richtig fette Baustellen mit der Karte und der Bewertung der Logs, die uns auch eigentlich zeitlich unter den Fingern brennen.