Integrate with Humanitix

[bethlakshmi]

This would be a 4th payment system - I would not remove any of the others, though I might spend a bit of time looking at on/off switching for them.

Humanitix (and how we want to use it) has a different ticket structure than we've had for the others, so this is a morph of the data model and also a fairly different API structure.

Data Design:

Here's how I plan to map Humanitix data concepts to GBE:

• Humanitix [Event](https://events.humanitix.com/gbe-test-by-betty?_gl=1*1t0ltfh*_ga*MTg4ODYxMDU2NS4xNjk1NDIxNjA1*_ga_LHKW5FR9N6*MTY5NzkyMDk2NS41LjEuMTY5NzkyMTQ2MC4zMy4wLjA.) - is basically the whole conference. Although it has a lot of what we call a TicketEvent, I propose that syncing it is damn near useless, because the whole www.burlesque-expo.com website is this "event".
• Humantix Ticket Type - (Main Event, Rhinestone Review)- roughly analogous to our idea of TicketItem - a thing you sell for a price that gives access to a thing at a date/time. I think the logic here is that our TicketItem is 1:1 with their TicketType and we make a TicketEvent the first time we encounter a specific start time/day for a ticket type and we name it whatever the ticket type is called. Example - we have 2 ticket types for the Main Event and the Rhinestone Review (General Admin, VIP). The first one we sync gets a new TicketEvent (say it's RR, General Admin), then the second time we see the same start time, we figure it's the same event (RR, VIP) and link the two to 1 ticket event in our system. Main event tickets get a different ticket event cause they have a differerent start time.
• Ticket Package - a Humantix specific thing - I would suggest saving this, too as a ticket item and making a realation ship where ticket items can contain other ticket items. OR I could make a new data object for the package...

CHALLENGES: 1 - there is no ticket type ID. I have a question pending to Humantix on this. This is a problem, since with no unique ID, I have to rely on something mutable to recognize already synced tickets on a repeat sync. So if a title changes, I make a NEW ticket type, because I can't tell if it's the same as a previously named type. It also makes deducing the package/ticket type relationship impossible from the API.

Limitations:

• This way of selling/packaging tickets does not give me a unique URL per ticket type. The URL is per event, and users buy tickets from the one URL.

Requirements to meet on the GBE side.

Right now we have:

• on a given event's description, we show them a URL to buy tickets. With Humantix, the URL is universal - it's always a slug for the event - so make sure we aren't doing multiple links with the same URL over and over.
• a public ticket list showing folks what they can buy - no big changes
• a list showing what a given user has bought - shows up in several places - on their dash, in a welcome letter, and in views registration can see (mostly the user landing page). I think no big change here.
• Editing capability for the ticket manager on the GBE site - will need changes to see the packages.

This is definitely a draft and not a done deal.

[bethlakshmi]

OK, I'll turn this into real docs in the Wiki later, but here in the comments is going to be notes with highlights Scratch may want to weigh in on.

1 - I decided that TicketTypes (Humantix tickets) and TicketPackages are going to both be "TicketItems" in our models - as they are both sellable things and so will be represented in Transactions. I made two subclasses for them so that:

• TicketTypes can now link to our scheduled events - which is really how this is going to work
• TicketPackages can contain a set of ticket types (0 or more), but cannot link to an event. I also gave them the qualities of "is_conference" - ie, the option of being a Scholar pass, and "wholeshebang" - ie is a Whole Shebang package. These two qualities are useful, so that the person setting this stuff up doesn't have to link all the conference classes, or all the everything (except master classes) - flipping these switches will do that linking automatically.

[bethlakshmi]

@burlexpo - OK, question. There are 3 ways to set ticket costs in Humantix:

• a cost - it's jut a number.
• a min/max range - easy for me to sync, we already have the concept of minimum cost in our system. I don't actually save the maximum, because it doesn't show up anywhere.

CHALLENGE: There is a set of cost options, which looks like this:

I don't have a place to store multiple costs. Of note - there's no way to control the quantity of each option. You can't sell 100 tickets at $10, then 10 VIPs at $50 - it's a straight list for people to choose and there's no verbiage you can attach to the prices saying anything at all.

Options on my end: 1 - super easy - skip it, we're never gonna use this. If this option is used, the cost on our end will be $0, which will unfortunately display in some views. 2 - not that much work - just save the lowest cost and label it as a minimum (same as the min/max range) 3 - really a PITA - add multiple costs to ticket items so that I can store all costs. Then figure out where/how to display this.

Any preference? Skipping it until I hear otherwise.

[bethlakshmi]

@burlexpo - QUESTION 2:

start and end date on ticket sales

These are settable in the ticket type section of Humanitix. But they don't show up in the API anywhere that I can find (I really think I looked everywhere).

What I've done in the past was to sync the date and then stop displaying tickets when the date has passed. It can also be overwritten by the user - so it CAN be set manually.

The options here:

• check in with the Humantix folks and see if I'm missing something (I'd prefer to wait and aggregate any other questions I have)
• actively sync the 'enabled/disabled" field to see if that keeps us in lock step with Humantix (can test it). Still suboptimal, because I think I show the dates in some places.
• do something annoying to the admin (you) - like emailing you when a new ticket arrives and tell you to set it.

This IS a new feature if we're asking them to add it to the API. I can see why they may not see value in exposing it.

Not a blocker for me... will continue with basic stuff while we talk.

[burlexpo]

@bethlakshmi

Q1: Skip it Q2: I'm pretty sure that a ticket that has expired or is not yet on sale is "disabled". So try testing that

[bethlakshmi]

Q2: Playing with it yields no change in disabled/enabled status. I mailed to Humanitix with the mystery.

[bethlakshmi]

FYI - chugging along (as can be seen by commit emails).

Done so far:

• humanitix import of events, ticket types, and packages
• display of these 3 things in a humanitix friendly way in the manage tickets list view
• edit of ticket types and packages including their special aspects - ticket types can link to GBE events, and packages can be whole shebangs, conference only and hold ticket types.
• added a "slug" to the ticketed event because we need that to compute the URL for Humanitix ticket buying. Also made that editable in our manage view.
• fixed up the grid of event to ticket display so that linking of events to ticket types & packages works the same as it did previously for the ticket event level.

TODO:

• make the display for the new ticket types & packages look good for ticket buyers, ie, this page: https://www.burlesque-expo.com/ticketing/
• Figure out what to do about the per event display - where we have a "get to this event by buying these tickets...." shown.
• Make sure the ticketed event creation works w Humanitix - I built a little linker into that, and now it links differently.

Going to another ticket for:

• transactions - there's been so much just for ticket import, I'm going to do the import of the buyer transactions separately. That includes - humanitix sync, checking out the display of manage transactions, the display on the user's home page, and double checking the comping.
• for later still - talk about how we want to do act/vendor payment going forward - do this via Humanitix? OR keep it paypal? As is, you'd want to make a SEPARATE event for act bid and vendor bid, respectively, as I didn't port any of the controls for that to a ticket level and it'd be easier to segregate, I think. But let's talk later.

[bethlakshmi]

OK, got another question for @burlexpo - working on "make the display for the new ticket types & packages look good for ticket buyers, ie, this page: https://www.burlesque-expo.com/ticketing/"

Situation - we are likely to have more than 1 ticket type per event. For example, the Main Event and Rhinestone Review often sell VIP tickets at a higher price. So we have, for example:

• Main Event - General Admin - $50 - 1 ticket type
• Main Event - VIP - $100 - another ticket type

Now with Humanitix, the Event level is the whole conference. So when I've been showing ticket options in previous years I did something like this:

So that for the given event, we show:

• the event name
• a pretty icon
• a bunch of enticing bullets
• a price range

Previously, the first 3 items came from the Ticket Event - which is now the whole conference - so that's a no-go. I figured out I can reshuffle the ticket type to GBE scheduled Event link so that I can get the event name from the GBE scheduled event, and then calculate the min/max ticket prices by comparing all the ticket types associated with that event.

So that leave the problem of the pretty icon and the enticing bullets.

I can do 1 of two things:

• don't even try the min/max thing - show every ticket type separately, attach the icon and bullets to the ticket type.
• do the min/max calculation, and then pick an arbitrary, currently visible, but predictable ticket type and display it's icon and bullets.
• figure out some other way to store the icon and bullets and associate them with the gbe scheduling event besides the ticket type... gets messy, but will ponder today while shopping.

So question - @burlexpo - do you have a preference of those 3 options?

And if I do what I think is easiest - pick an arbitrary ticket type and display it's icon/bullets - what algorithm would you prefer? I could do things like - always pick the highest price, most recently edited, alphabetically first title... I lean towards highest price - because we usually have cheaper tickets that expire, or sell out as time goes on. But the highest price tickets are always the most available, so work as a good long term container for other settings.

[bethlakshmi]

OK, another open question - packages. Very similar problem, slightly different issues. We could very well have 2 packages of, say, Whole Shebang. We often have done:

• first 10 Whole Shebangs - super cheap!
• Whole Shebang early bird special
• Whole Shebang full price

With Humantix, I can't think of a way (unless I fake it with extra work for me and @burlexpo) to aggregate those 3 Whole Shebangs into 1 package on our Buy Tickets display. They don't have the same name, they won't have the same ID.

Right now I'm stuck with having those 3 Whole Shebangs show up as separate packages that don't have anything do with one another. Which means that any extra description has to be done by Scratch on all of them. Alternately, I could develop some sort of thingy that collects them and provides the place where the icon and bullet points can be provided.

Because this has gotten intense, I'm also going to post what I have so far so we can look at it on the test site. You can preview it here:

https://burlesque-expo-stage.us.aldryn.io/ticketing/

[burlexpo]

A couple of thoughts -- mostly, "are we reinventing the wheel?". I understand that when the only tool you have is a Pyhon Developer than all problems look like a nail... but it seems like Humanitix has some features we may want to use instead of writing our own.

1) Buy Ticket Widget -- shows a list of available tickets but can be imbedded in our website 2) Multiple prices for the same ticket -- https://humanitix.atlassian.net/servicedesk/customer/portal/2/article/1236992683 3) I can't find the Quick Start page for Discounts (I can find it but it's 404), but I'm pretty sure there's a way to offer prices for a limited time to do what we want to do in that department

[bethlakshmi]

1. Yep, if you like what's shown here: https://humanitix.atlassian.net/wiki/spaces/CS/pages/1228538204/Sell+tickets+and+showcase+events+on+your+website+with+widgets?parentProduct=JSM-Portal&parentProductContentContainerId=10114&initialAllowedFeatures=disable-login-flow.disable-share&locale=en-US#[hardBreak]%F0%9F%8E%AB-Buy-tickets-widget

I can definitely set you up with a page for that - can probably even do it w/out code using Django CMS and the embedded code. Can't change the look and feel though, so it will look a bit transplanted.

3. on the page you linked, do you mean "flexible pricing" - that is different from multiple pricing. It's stuff like ranges or lists - but for each ticket type there is 1 price (however flexible) and 1 date range.
4. Discounts - is it this? https://humanitix.atlassian.net/servicedesk/customer/portal/2/article/1276674650 - this seems to be all about codes.

[burlexpo]

1. I went to look and see if the L&F of the widget was CSS controllable. Can't tell if it is.
2. (3) Allows us to set a PWYW for specific ticket type and date. So, we could create a ticket for "Rhinestone Revue" and someone could select from a list of prices we set; one VIP price, one standard price.
3. Yes, but item 8 on their list is "set a time when codes are valid" and since you can create an automatic discount on certain tickets, I think you could set things up to say

When you purchase ticket WHOLE SHEBANG automatically apply DISCOUNT "2024"

and then DISCOUNT 2024 says

1/1/2024-1/31/2024 Discount =50% 2/1/2024-2/29/2024 Discount=40% 3/1/2024-3/31/2024 Discount=30%

etc

[bethlakshmi]

1 - usually messing around with CSS on an embed like this is asking for trouble. They definitely don't expect us to do that, so when/if they ever change the HTML, the results will be unpredictable and we'll never know when that happens. What they give us is a script which loads both the content and the HTML around it. What we paste into our site, looks like this:

`

` 2 - so that list of prices what I was asking about a few days ago. The list gives no context, so they won't really know that by purchasing the most expensive ticket they are getting priority seating - it's just a list of costs. Also - I don't have a way to store that data right now - I can build it, but not sure if it's worth it. 3 - OK. That seems really complicated for the user? And it also means if I'm doing anything about it on our side, I'm writing a whole other aspect of the code to work with discount codes. I think we're at a point where we need to chat IRL. I'm starting to wonder what the requirements of the GBE site should be here, and how much of their ticketing system I should sync.

[bethlakshmi]

FYI - I put up a test page with the ticket list widget from Humanitix - here: https://burlesque-expo-stage.us.aldryn.io/humantix-embedded-widget/?edit_off=true

The "Example of list" is what the price list of option 2 gives you - the list is just a list of costs, no other text available.

The look of it is pretty good - IMO - neutral enough that it's not too jarring, and the fact that they can walk all the way through payment w/out leaving our site is neat. The only odd thing is that the login/payment here is separate from anything related to our login - and that's just how it will have to be.

If we go with this... I'm wondering what part of ticket integration needs custom code? We show ticket stuff on the event pages, and on the user's home page...but that's a lot simpler... do I want to even try to do a purchase tickets page?

[burlexpo]

Hmm... yeah, the "Example of List" isn't great, but we might be able to put the text elsewhere. It's a diferent way than we've done things historically. It saves some work and creates others.

I'm around tomorrow during the day if you want to get together to discuss

[burlexpo]

3 - OK. That seems really complicated for the user? And it also means if I'm doing anything about it on our side, I'm writing a whole other aspect of the code to work with discount codes.

No, it's complicated for me -- it's invisible to the user. The prices just change automatically.

[bethlakshmi]

Sounds good. I have meetings 12-2 intermittently but otherwise free. Will probably book some sort of morning workout.

[bethlakshmi]

First round done - follow on tickets created. On the live site, I turned on Humanitix, turned off Eventbrite and I'm just waiting to make sure the timed sync pulls in the event the way it should. The Buy Tickets page has been created and is live.

[bethlakshmi]

Turns out I needed to integrate the ticket sync. They can be synced manually with the button, but i forgot to implement the cron job way of doing it! (D'oh). so I manually synced the tickets and set them up. And will do the automated version on the #563 ticket

[bethlakshmi]

Fixed with #567 - and I just configured Divio with the new scripts. It bears monitoring for a bit - we have no transactions yet. Would love to see some syncing up after we well them. :)