|
utahhockey
|
February 28, 2016 at 12:33 pm
After the change to EE4, and the addition of event datetimes (awesome btw), we lost the ability to have unique barcodes within an event. This has caused the ability for fans to pass around tickets and we would like the ability to enable unique barcoding.
|
|
Tony
|
February 29, 2016 at 6:08 am
Hi there,
Can you provide some additional details on how you have the tickets/datetimes setup or could link us to one of the events so we can run some test registrations?
Multiple registrations should have unique barcodes.
|
|
utahhockey
|
February 29, 2016 at 5:24 pm
Event Datetimes are listed as game 1, game 2, game 3, etc.
Available tickets are listed as student ticket option 1, student ticket option 2, adult ticket option 1, adult ticket option 2, etc.
http://universityofutahhockey.com/events/2015-16-tickets/
After our issues with multiple event registration in EE3, Seth recommended we use a single event with multiple datetimes. It is a lot easier for a fan to purchase a season ticket this way. It is also easier to scan the tickets when all tickets end up in a single event. However, this changed gives a ticket purchaser the exact same code for every event datetime within a ticket when “season tickets” are purchased.
|
|
Tony
|
March 1, 2016 at 7:20 am
I see, the reason for this is because it’s a single registration that grants access to multiple datetimes so you will only have a single barcode/QR code. Currently you can not have a single registration with individual barcodes for individual datetimes within a single event.
However once a user has been checked in for an individual datetime you can prevent any other checkins for that specific datetime which means it shouldn’t matter that the ticket is the same as it can’t be checked in again. Are you checking the users in when the arrive?
|
|
utahhockey
|
March 1, 2016 at 2:09 pm
Totally understood. There was some hit/misses with the check-in process early on, so we have a policy to never “argue” with a fan about their tickets. Since we find ourselves in this “human problem” that we are trying to engineer our way out of, it appears we could go back to the multiple event model, or simply print the tickets.
|
|
utahhockey
|
March 1, 2016 at 2:11 pm
Speaking of printing, is there a method to generate valid codes in EE, or assing codes? We could generate 500 valid codes, get them printed, and then go back in and asssing names/emails to the codes. Thoughts?
|
|
Tony
|
March 2, 2016 at 2:04 am
If you will never argue over the validity of a ticket then regardless of how EE handles them you will run into this problem. For example if a registrant prints and photocopies the ticket and then passes that around to 3 other people, regardless of how the code is generated those 3 other people still have a ticket. So then the ‘real’ registrant checks in and those 3 others then try to check in, your in the same situation you are now in that the barcode will show its an invalid ticket.
The only way to be sure if a ticket is valid is to check it against the current check-ins and ensure it hasn’t been used on the current datetime. Other than that you would need a completely closed system, printing the tickets yourselves and having them printed with security measures such as holograms to prevent copying.
One option is to remove the code from being output on the ticket, so then the QR/Barcode still shows up, but the code itself is not visible on the tickets. So these two sections would no longer show – http://take.ms/Yx5KV
That ticket would then look like this – http://take.ms/eII2a
That way it is not obvious that the code is the same throughout the datetimes, would that work?
Speaking of printing, is there a method to generate valid codes in EE, or assing codes? We could generate 500 valid codes, get them printed, and then go back in and asssing names/emails to the codes. Thoughts?
The tickets are built from the registration data, so to do that you would need to add 500 registrations to the event but you’ll run into problems assigning those registrations to the new users. The barcodes aren’t separate from registrations, they are used as a way to identify a registration, the registration then tracks check-ins etc itself.
I think trying to generate those registrations and assigning them to new users will cause more problems than your current setup.
|
|
utahhockey
|
March 7, 2016 at 6:11 pm
Tony, thanks again for your time.
Removing the visible code isn’t a bad idea, but it still leaves us vulnerable to passing tickets with barcodes since we do scan all tickets. We could always return to making a season consist of multiple events (and use the multievent plugin) but it could just create “different problems”.
As of today, the logical solution is a single event and ticket printing. But then we have issues with late purchases etc. That said, if we pre-generated Jane Doe in the system, would we be able to update that registration with another name and email address? We understand it “could” create problems.
|
|
Tony
|
March 8, 2016 at 5:16 am
Removing the visible code isn’t a bad idea, but it still leaves us vulnerable to passing tickets with barcodes since we do scan all tickets.
I’m not sure I understand, if you are scanning the tickets how does this cause further problems?
As of today, the logical solution is a single event and ticket printing. But then we have issues with late purchases etc. That said, if we pre-generated Jane Doe in the system, would we be able to update that registration with another name and email address? We understand it “could” create problems.
Yes you can.
When you view the registration list you can edit the contact from there – http://take.ms/1KdxB
Or from within the registration itself – http://take.ms/wbNNj
However you need to be aware that EE creates ‘contacts’ from registration details. A single contact can be assigned to many registrations (the same person can create multiple registrations), if when you register EE finds a contact with the same details they you are using the registration will be assigned to that contact.
If you then change the contact details for that registration, ALL registrations assigned to the contact will show the new details.
So yes you can create dummy registrations, if you use unique details for each then edit them later.
|
