[gelöst] Eintrittskarten

Na dann nimm doch einfach die Node ID als Nummer. Die ist eindeutig.

Aber die ist (zumindest einigermaßen) fortlaufend. Dadurch kann man sich ein Ticket kaufen und hat es dann leichter weitere zu fälschen. Da wir komplett auf Onlineverkauf umsteigen wollen, wäre eine eindeutige Nummer das einzige, womit wir am Eingang verifizieren könnten, dass die Karte tatsächlich gekauft/bezahlt wurde. Ich vermute doch, dass die Großen das genauso machen mit den Tickets, die man zuhause selbst drucken kann (Strichcode=eindeutige, zufällige Nummer).

Warum kann man denn damit weitere Tickets fälschen? Das Ticket kann doch einfach die Node-ID samt persönlicher Daten (Vorname, Nachname, Geburtsdatum usw.) enthalten und dann kann das Ticket doch einwandfrei zugewiesen werden, oder?

--> Aha, Ticket, Nummer 123, gekauft von Max Muster, geboren am 01.02.1960;

Also geben wir in eine selbst erstellte View (oder eigenes Modul usw.) die Node-ID 123 ein und lassen uns die entsprechenden Felder ausgeben. Und da sehen wir, das Max Mustermann, geboren am 01.02.1960 das Ticket gekauft hat, fertig.

--> Nächstes Ticket hat die ID 321, gekauft von Maria Muster, geb 03.04.1970;

Die Suche ergibt, dass der Node entweder nicht existiert oder von Tom Tester, geb. 05.06.1950 gekauft wurde. Das ist doch eine eindeutige Sache, oder?

Der Node wird nur bei einer erfolgten Bestellung erstellt. Das kann man dann noch erweitern, dass eine Checkbox im Node erst aktiviert wird, wenn die Bestellung bezahlt wurde. Damit sind nur Tickets mit Node-IDs gültig, deren zugehöriger Node auch existiert und die Checkbox aktiviert hat. Damit wäre das ganze Problem doch aus der Welt, oder nicht?

Alternativ kannst du in Computed Field auch per Zufalls-Generator eine zufällige Zahl erstellen lassen. Dann prüfst du per db_result, ob diese Zahl schonmal als Wert verwendet wurde. Wenn ja, wird eine neue erzeugt usw. Das machst du so lang, bis eine eindeutige Zahl gefunden wurde und erst dann gibst du die Zahl zurück. Das ganze würde ich mit einer möglichst großen Zahl machen (12-stellig oder so). Damit vermeidet man (so gut es geht) erstens, dass zwei User gleichzeitig die gleiche Zahl bekommen (dann gibt's nämlich Probleme) und zweitens dauert dann die Erstellung einer neuen Zahl evtl. nicht so lang, wenn schon einige Zahlen vergeben sind. Das wird gespeichert und schon hat man seine (so gut wie) eindeutige Zahl.

Um zu verhindern, dass zwei User gleichzeitig einen Node erstellen und die gleiche Zahl bekommen und speichern, kann man evtl. noch Unique Field verwenden, damit dürfte auch der unwahrscheinliche Fall, dass eine Zahl zweimal verwendet wird, ausgeschlossen sein.

Ergänzen kann man das ganze noch mit dem Barcode-Modul, wenn man will und es einem hilft.

Allerdings wüsste ich nicht so recht, wozu man den Aufwand der zweiten Variante betreiben sollte, wenn man mit der ersten genauso gut und absolut sicher eindeutige Zahlen bekommt.

Ja, so würde es wohl gehen. Allerdings missfällt mir die Idee, dass man seinen Name beim Eintritt verraten muss. Vllt. hat man das Ticket ja auch für jemand anderes gekauft. Aber gut, da könnte man statt eines selbst eingegebenen Namens auch eine Zufallszahl nehmen, die dann zur richtigen Node-ID passen muss.

Das Problem, dass wir am Eingang dann durch durch das Prüfen der Nummern Zeit verlieren, die wir ob der ohnehin schon vorhanden Schlange eigentlich nicht haben, dürfte bei der Idee selbst gedruckter Tickets so oder so nicht verhindert werden können (Es sei denn wir setzen einen Strichcode-Leser ein, was sich preislich nicht lohnen würde).

Somit danke ich dir mal für den Denkanstoß und werde schauen, wie die Idee mit den beiden zusammengehörigen Nummern ankommt.

Nunja... wieso dann noch die Node-ID am Eingang überprüfen...

Einfach nur das Zahlenfeld abgleichen (am besten Hexadezimal, da sieht mans schneller) sollte doch genügen.

Durch die Node-ID würde die Nummer in jedem Fall eindeutig. Ich müsste mir also keinen Code aus den Fingern saugen (worin ich echt nich gut bin), der sicherstellt, dass die Zufallsnummer nicht schon einmal vorkam. Außerdem ist so auf einer gedruckten Liste die Nummer schnell zu finden, wenn die ersten drei Ziffern quasi fortlaufend sind. Eine Ticketnummer könnte dann also z.B. so aussehen: 331-173027459127
Wobei die 331 die Node-ID ist, die in der Liste schnell gefunden werden kann und mit dem Rest der Nummer abgeglichen werden kann.
Also die Idee gefällt mir jetzt, auch weil sie einfach ist. Fehlt nur noch die Möglichkeit, das ganze dann hübsch zu drucken. Ein PDF würde mir gefallen. Aber da werd ich schon was finden.

Anderer Ansatz:
Eigentlich sind doch Sitzplätze eindeutig numeriert.
Damit ergäbe sich aus Vorstellungsnummer und Sitzplatznummer eine eindeutige Nummer.
Angenommen, jeder Sitzplatz wäre in einem Shop ein Artikel, der nur 1x verfügbar ist, wäre das Ticket kein Problem mehr, schätze ich.

Interessanter Ansatz. Wir haben zwar keine Sitzplätze, aber eine Grenze für die Besucherzahl. Das wäre eine Möglichkeit, sicherzustellen, dass nicht zu viele Karten gekauft werden und wäre bei Sitzplätzen noch eine schöne Möglichkeit, dass sich die Besucher aussuchen, wo sie sitzen wollen. Aber ich weiß nicht ob sich der Aufwand für mich lohnt. Bisher hat die Seite keinen Online-Shop und ich müsste 1200 Artikel anlegen. Wir haben noch keinen Zeitdruck, also schau ich erst mal, wie die Ideen ankommen.

Wie ist das denn nun im Detail gelöst wurden? Ich habe ein ähnliches Problem mit Eintrittskarten.

Darauf gibt es zwei unterschiedliche Antworten. Gelöst wurde es für uns im Endeffekt so, dass mir jemand sagte, wir machen doch keine Onlinetickets und ein klassischer Webshop, in dem man Papier-Tickets kaufen kann, reiche aus.

Aber wie das oft so ist, natürlich nicht, bevor ich schon eine fast fertige Lösung hatte.

Aus der Erinnerung:
Es gab einen Content Type "Eintrittskarte" mit Feldern für Name, Anschrift und Email-Adresse und ein Computed Field für eine Kartennummer. Diese Kartennummer setzte sich aus einer Kurzschreibweise der Veranstaltung, der Jahreszahl, der Node ID und einer zufällig generierten Buchstaben- und Zahlenfolge (16-stellig oder so) zusammen. Nodes dieses Typs konnten von Gästen angelegt werden. Nach dem Abschicken des Formulars wurden die eingegebenen Daten, die generierte Kartennummer und die Bankverbindung angezeigt (kann mit node.tpl.php gelöst werden, Views wäre aber besser, damit man dann nicht einfach durch die Veränderung der Node ID in der URL die Bestellungen anderer einsehen kann). Eine Einbindung eines Zahlungsdienstes war bei uns nicht gewünscht/erforderlich. Gleichzeitig wurden die Informationen auch noch mit Rules per Email verschickt. Das "Printer, email and PDF versions"-Modul stellte einen Link bereit, über den man sich eine PDF-Datei erzeugen und runterladen konnte. Dieses Modul erlaubt es, den Inhalt dieser Datei per tpl.php zu gestalten, sodass in der PDF-Datei eine fertige Eintrittskarte zum Selbstausdrucken enthalten war.

Benötigte Module für Drupal 7:
http://drupal.org/project/computed_field
http://drupal.org/project/rules
http://drupal.org/project/print
http://drupal.org/project/node_access oder http://drupal.org/project/content_access oder Ähnliches

Wenn du eine genauere Erklärung oder mehr Details brauchst, frag ruhig noch mal.

Okay, danke für die Antwort.
Ich will das ganze noch mit dem Zahldienst PayPal und einem Barcode kombinieren. So das man dann die Eintrittskarte einfach nur scannen muss und sieht wer da ist und wer nicht.
Das ganze könnte man ja auch mit Webform versuchen, da es ja hierfür auch PayPal Module gibt.

Gute Idee. Zum Codescannen mit dem Smartphone braucht es ggf. etwas mehr Licht, damit es richtig zuverlässig geht. Sonst braucht man für jede Karte 'ne halbe Minute, wie mit billigen Barcode-Scannern.

Hallo PowerMan,

ich habe gerade deinen Beitrag gefunden. Ich stehe gerade vor einer ähnlichen Herausforderung.

Ich will online Tickets verkaufen. Für jedes gekaufte Ticket soll ein PDF erzeugt werden, in welches ein einzigartiger Barcode gedruckt wird. Dieser Barcode soll dann zur Entwertung am Einlass des Events dienen. Wie hast du das letztes Jahr gelöst? Hat es geklappt, wie du es oben schilderst?

Vielen Dank & Gruß

Michael