We have a desired customization where we want to send the customer to the pre-cart with a custom form generated based on the contents of their cart. We don't want them to see the form until they have added all their events and are ready to checkout. However if I simply set the desired HTML content to the @PageText variable in the Checkout validation section of the validate cart procedure, it simply appends this code to the top of the payment page, and we simply don't want them to access this page until they have completed the custom form on the pre-cart. I added an additional script to the beginning of the @PageText variable to redirect them to the components/precart page, but after that it just keeps sending them back to the cart/details page.
Does anyone have any insight on how to redirect to the pre-cart using the checkout validation point, and also set the rest of the content on the page at the checkout validation section as well? I suppose I could try to set the pre-cart page text as they build their order through the single ticket added validation point, but not certain how to prevent them from seeing the pre-cart until they attempt to check out.
Jesse,
I am not aware of any way to do that in Version 15. I suppose there might be a possibility that the Version 16 upgrades to the customization path might make that a possibility, but otherwise I am not aware of a solution for you. I suppose the question could be WHY you want to delay the form until they have finished adding things to their cart and to see if there is any way to restructure the form such that either it would be different for each item they add to their cart or they could fill it out after adding the first item to their cart and then each successive item would simply reload the same form with the information already loaded into it in case they need to adjust it due to the new contents. Alternatively, if it is simply important that the form be filled out ONLY once, you could put a precart pass count and disable it once it has been filled out the first time. But I can see where these would also be non-optimal ideas.
Last ditch solution would be to somehow embed a form on the checkout page but use some Javascript to disable the button that allows them to checkout until they have in fact completed the form.
None of these are what I would consider excellent solutions, but they are all I could come up with. Best of luck.
John A. Moskal II
Since we are apart of a university, we receive funding from the school for certain discount programs, but we have to ensure the discounts are going to the right students. The system has always been, show you ID at the box office to get your tickets, but we've received approval to allow online validations, and we've been granted access to certain pieces of data to allow our system to verify student status online. Normally 1 student could get their discount on numerous shows but only need to show their ID once to get the tickets. So the idea was they could order as many shows as they wanted to, and then before checkout we would ask them for validation based on the maximum number of student tickets requested for any one performance. But I do agree from reading the documentation on it, that it might not be possible as I had first thought. I do like the idea of asking for validation at the single ticket added validation point, and then "flagging" the order with the total validations and only sending them back to the form if they order additional tickets to a different performance requiring more validations. I think I had hoped to do it at checkout to make the logic and code a bit simpler, but I think doing it show by show would be still be a feasible solution.Thanks John!
We do the same thing (broken right now, trying to fix!). It's handled in two parts: there is a TNEW customization built by Extended Services that detects the reservation of a ticket at a specific price type, and transfers over to an independent web app (the broken part) which sends the customer to the campus authentication servers. Once authenticated the web app receives a users id which it then looks up in the campus LDAP database to determine campus affiliation status, then sends that status (or statuses!) back to the TNEW customization. The customization then keeps track of userid/status pairs, maps those to a table with price type and required status, and determines if the reservation can proceed. If not it gives the option to try a different authentication or remove the tickets. The userid/status pairs are saved in the session, so reserving tickets in a different performance won't need a check if that status is already authenticated, but if multiple tickets of the controlled price type are reserved for one performance then multiple authentications are required.
That's kind of the logic we were thinking of, in fact our marketing manager mentioned UC Berkeley when we were discussing ways to go about this. I think we ended up with doing a data dump through Grouper, but it will only provide their IDs and no emails. So the TNEW logic path seems the same, except we'll be comparing it to static data stored right there in our impresario database as opposed to live data directly from the university system. We'll probably update once a week so the data will never be too old.Out of curiosity, does any part of your validation system prevent additional orders. So like during the purchase path, it stored the validation point I'm guessing against the order number and performance numbers? But what happens if they don't complete the order? How do you differentiate between the orders that go through and the ones that don't? So for instance if you complete the order, does your system prevent them from ordering additional student tickets again for the same performances? And if they abandon the order, your system allows them to go back in and order again and validate the same student credentials without issue? I suppose you could add to the cart deletion validation to remove the validation, but what if they just up and abandon the cart entirely? This is the one scenario I'm having the most trouble wrapping my head around for our system.
We do not check against previous orders, so you can totally go in and buy 10 discounted tickets as long as you are willing to do it in 10 separate orders (each with an order fee). The box office does have some anti-scalping processes that would catch that sort of thing if it was out of hand (this is a general issue with Tessitura/TNEW and ticket limits).