Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Ownername OC

  • zuletzt eingeloggt am: xx.xx.xxxx

  • Email invalid: ja/nein

  • ✉ (Nachricht schicken)

OC-Wegpunkt (Klick ruft Listing auf)

  • 👁 (Listing beobachten)

  • ❗(Listing zur Prüfung zuweisen/freigeben)

  • ❗(Listing melden)

Ownername GC

  • ✍ (Ownernamen manuell anpassen)

GC-Wegpunkt (Klick ruft Listing auf)

  • ✍ (GC-Wegpunkt manuell eingeben/anpassen)

Bemerkungen zum Owner eintragen:

  • es ist nur eine sind mehrere Bemerkungen möglich

  • die jede Bemerkung wird automatisch mit Datum und Uhrzeit versehen

  • die zuletzt eingetragene Bemerkung kann editiert werden

  • (Alle Bemerkungen zu den Ownern können in einer separaten Übersicht aufgelistet werden.)

bereits vorhandene Bemerkungen zum Owner werden hier angezeigt

Bemerkungen zum Listing eintragen:

  • es sind mehrere Bemerkungen möglich

  • jede Bemerkung wird automatisch mit Datum und Uhrzeit versehen

  • die zuletzt eingetragene Bemerkung kann editiert werden

bereits vorhandene Bemerkungen zum Listing werden hier angezeigt

Offene Fragen:

  •  Beim Owner ist nur ein Bemerkungsfeld notwendig oder wie bei den Listingbemerkungen auch mehrere?Ist eine 'id'-Spalte notwendig, obwohl eine andere Spalte bereits eindeutig ist?
  •  reicht ein varchar(255) für Benutzer- und/oder Listingkommentare? Was ist Maximum? .. longtext

Datenbank, bestehende Tabellen:

  • Ownername OC: user / username

  • zuletzt eingeloggt: user / last_login

  • OC-Wegpunkt: chaches / wp_oc

Neue Datenbanktabellen:

  • ❌ Informationen zu den Verbindungen eines OC-Users zu anderen Nodes, wie GC, speichern

    • support_user_relations

      • id (fortlaufende ID in der Tabelle)

      • oc_user_id (OC User-ID)

      • node_id (Info, von welchem Node diese Infos stammen, siehe Tabelle ‘nodes’ ..)

      • node_user_i (GC/Fremdnode User-ID, nicht der Username! Auf diese ID muss immer verlinkt werden können, auch wenn sich der Ownername ändert.)

      • node_username (Name des Users auf GC/Fremdnode. Diese Info könnte z.B. von einem PocketQuery/GSAK-Import stammen)

      • user_name_maintained (Name des Users auf GC/Fremdnode. Diese Info wird vom Support eingetragen, ansonsten ist das Feld identisch zu node_username. Änderungen des Namens werden als Systemkommentar beim User hinterlegt (siehe unten, Tabelle support_user_comments), damit Namensänderungen des GC/Fremdnode-Users nachvollziehbar sind.)

  • ❌ Kommentare zu OC-Usern speichern

    • support_user_comments

      • id (fortlaufende ID in der Tabelle. Es sind mehrere Kommentare zu einem Nutzer möglich.)

      • oc_user_id (OC User-ID)

      • comment (Feld für Notizen des Supports zu diesem OC-User)

      • comment_created (Datum der Erstellung)

      • comment_created_by (OC User-ID des Erstellers) (ist nicht relevant bei nur einem Kommentarfeld)

      • comment_last_modified (Datum der letzten 'comment'-Änderung)

  • ❌ Bemerkungen zu OC-Listings speichern.

    • support_listing_comments (Kommentare zu OC-Listings speichern)

      • id (fortlaufende ID in der Tabelle. Es sind mehrere Kommentare zu einem Listing möglich.)

      • wp_oc (OC Listing ID)

      • comment (Feld für Notizen des Supports zu diesem OC-Listing)

      • comment_created (Datum der Erstellung)

      • comment_created_by (OC User-ID des Erstellers) (ist nicht relevant bei nur einem Kommentarfeld)

      • comment_last_modified (Datum der letzten 'comment'-Änderung)

  • ❌ Markierung von OC-Listings als 'Bonuscaches' bzw. als 'zu Bonuscaches zugehörig'.

    • support_bonuscaches

      • id (fortlaufende ID in der Tabelle.)

      • wp_oc (OC Wegpunkt des Caches)

      • is_bonus_cache (ja oder nein. Vermerkt, ob dieser Cache vom Support als Bonuscache markiert wurde)

      • belongs_to_bonus_cache (ist leer oder enthält einen OC-Wegpunkt. Der Wegpunkt wird vom Support eingepflegt.)

  • ❌ Informationen zu Listings von Fremdnodes speichern.
    Diese Informationen könnten z.B. von einem (PocketQuery-/GSAK-)GPX-Import stammen. (Eher nicht durch händische Eingaben..)
    Bei einem weiteren GPX-Import werden Änderungen an bestehenden Infos als Listingkommentar (siehe oben, support_listing_comments) hinterlegt, womit sie auch später noch nachvollziehbar sind.

    (mögliches Szenario: Es wurden bereits einmal Daten von GC-Listings in die Datenbank importiert. Nun erfolgt ein weiterer Import. Listinginformationen, die sich gegenüber den bereits gespeicherten Infos geändert haben, werden bei den betroffenen OC-Listings als Listingkommentar hinterlegt (siehe oben, Tabelle support_listing_comments) und danach in der Datenbank gespeichert (alte Daten überschreibend).
    Damit der Support alle diese Änderungen noch einmal sehen und ggf. bearbeiten kann, soll es eine entsprechende Unterseite geben, die diese Infos auflistet. Zwecks besserer Übersichtlichkeit sollte dann ein Datum ausgewählt werden, anhand dessen die Ergebnisliste gefiltert wird.)

    • support_listing_infos

      • id (fortlaufende ID in der Tabelle)

      • wp_oc (OC Wegpunkt des Caches, auf den sich bezogen wird)

      • node_id (zeigt an, von welchem Node diese Infos stammen, siehe Tabelle ‘nodes’..)

      • node_owner_id (generische User-ID des Nodes)

      • node_owner_name (Ownername. Wird bereits inTabelle support_user_relations gespeichert!)

      • node_listing_id (generische ID des Listings. Wird diese Info benötigt?)

      • node_listing_wp (Wegpunkt des Listings)

      • node_listing_name (Listingtitel)

      • node_listing_size (Behältergröße. )

      • node_listing_difficulty (D-Wertung)

      • node_listing_terrain (T-Wertung)

      • node_listing_coordinates_long, .._lat (Ankerkoordinaten)

      • node_listing_archived (ja oder nein)

      • last_modified (Datum der letzten Änderung dieses Tabelleneintrags)

      • importstatus (kann diverse Status enthalten, z.B. ob der Eintrag bereits ausgewertet und verarbeitet worden ist)